From: Sam S. <sm...@gm...> - 2010-12-21 23:23:14
|
Hi, how hard would it be to implement a simple custom SMW data type that handles software version strings of the standard form "major.minor[.revision][ release-type]"? It would have to: - sanitize input data (e.g. ignore differences in spacing or capitalization, and synonyms, e.g. "2.0a"= "2.0 alpha" = "2.0 ALPHA" = "2.0.0 alpha1") and store/output it in a unified way - handle comparison and sorting, e.g. "1.1.0" < "1.10" < "1.10.2" < "1.10.3 alpha3" < "1.10.3 beta1" < "1.10.3 rc2" < "1.10.3" Is there any developer documentation or other resources that could help with this? (I have no prior experience in MediaWiki or SMW extension development.) Thanks, Sam S. |
From: Robert M. <mra...@gm...> - 2010-12-22 06:03:33
|
I'm no expert, but the way SMW is setup now, I would go about what you're trying to do like this: - Each page would four properties 1. Major version :: type:number 2. Minor version :: type:number 3. Revision version :: type:number 4. Release type :: enumerate, allows value: alpha1, beta2, etc. You would have to have a series of #IF statements to display it the way you want, but it takes care of the comparison problem and the sanitization problem. I can't write PHP, so that's what I'd do. -Robert On Tue, Dec 21, 2010 at 3:22 PM, Sam S. <sm...@gm...> wrote: > Hi, > > how hard would it be to implement a simple custom SMW data type that > handles software version strings of the standard form > "major.minor[.revision][ release-type]"? > > It would have to: > - sanitize input data (e.g. ignore differences in spacing or > capitalization, and synonyms, e.g. "2.0a"= "2.0 alpha" = "2.0 ALPHA" = > "2.0.0 alpha1") and store/output it in a unified way > - handle comparison and sorting, e.g. "1.1.0" < "1.10" < "1.10.2" < > "1.10.3 alpha3" < "1.10.3 beta1" < "1.10.3 rc2" < "1.10.3" > > Is there any developer documentation or other resources that could > help with this? (I have no prior experience in MediaWiki or SMW > extension development.) > > Thanks, > Sam S. > > > ------------------------------------------------------------------------------ > Forrester recently released a report on the Return on Investment (ROI) of > Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even > within 7 months. Over 3 million businesses have gone Google with Google > Apps: > an online email calendar, and document program that's accessible from your > browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > |
From: Jeroen De D. <jer...@gm...> - 2010-12-22 13:14:39
|
Hey, > You would have to have a series of #IF statements to display it the way you want, ... You can indeed do this. It can get rather messy though. > how hard would it be to implement a simple custom SMW data type that handles software version strings of the standard form "major.minor[.revision][ release-type]"? Not that hard, if you know how to create new data types. > Is there any developer documentation or other resources that could help with this? Sadly enough not. You can check out the existing SMW data types though, which can be found here [0]. [0] http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SemanticMediaWiki/includes/datavalues/ Cheers -- Jeroen De Dauw http://blog.bn2vs.com Don't panic. Don't be evil. -- |
From: Sam S. <sm...@gm...> - 2010-12-28 12:19:10
|
Hi again, and thanks for the answers. Personally, I feel more comfortable implementing the required logic in PHP rather than using complex MediaWiki parser functions statements. So I think I'll give the "custom SMW data type" thing a try... Looking at SMW_DataValue.php and SMW_DV_URI.php, it appears I need to write a subclass of SMWDataValue that implements at least the parseUserValue and parseDBkeys functions, plus some simple "get..." functions (getDBkeys, getSignature, getShortWikiText, getShortHTMLText, getLongWikiText, getLongHTMLText, getWikiValue), which altogether doesn't look too difficult. I have two more questions though: 1) How do I make the custom data type known to SMW, and how do I wrap up the whole thing as an extension module for SMW? (I couldn't find any documentation on that, either.) 2) Is the API considered "stable", or are developers of SMW extension modules expected to implement considerable changes for each new SMW release? Regards, Sam S. |
From: Jeroen De D. <jer...@gm...> - 2010-12-28 13:14:44
|
Hey, > How do I make the custom data type known to SMW, and how do I wrap up the whole thing as an extension module for SMW? You need a single hook. See line 69 at http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SemanticMaps/SemanticMaps.php?view=markup Further see this class on how to use this: http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SemanticMaps/includes/SM_GeoCoordsValue.php?view=markup Do note that this class is doing a bunch of stuff you don't need to worry about in your use case, such as creating a new database table. > (I couldn't find any documentation on that, either.) The only docs are the code comments in the SMWDataValue class, which explain how to derive from it, and how to implement the abstract methods, amongst other stuff. > Is the API considered "stable", or are developers of SMW extension modules expected to implement considerable changes for each new SMW release? No one is planning on changing it AFAIK. Also, backward compatibility is held into account, so you should not worry to much about this. On an unrelated note, this is the wrong list for these questions. You need sem...@li... Cheers -- Jeroen De Dauw http://blog.bn2vs.com Don't panic. Don't be evil. -- |