Hi, I'm trying to change my php code to work with SMW 1.6. (MW 1.16.0, SMW 1.6 alpha r89160) I updated the DB and data with the SMWAdmin functions. #ask queries seem to work ok.
I use the calls $property = SMWPropertyValue::makeUserProperty($propname); $ptype = $property->getPropertyTypeID(); where $propname is the name of a property. This seems to be valid in SMW 1.6 as it is used e.g. in file includes/parserhooks/SMW_Declare.php $property = SMWPropertyValue::makeUserProperty( $propertystring ); : $type = $property->getPropertyTypeID(); As far as I can see I run into problems when function getPropertyTypeID() calls function getTypesValue() which calls smwfGetStore()->getPropertyValues( $this->getWikiPageValue(), new SMWDIProperty( '_TYPE' ) ); $this->getWikiPageValue() returns a 'SMWWikiPageValue Object' which in function getPropertyValues( $subject, SMWDIProperty $property, $requestoptions = null ) is than passed as '$subject' argument to $this->getSemanticData( $subject, array( $property->findPropertyTypeID() ) ); Calling getSemanticData with an 'SMWWikiPageValue Object' as $subject causes an empty page because it seems it expects a 'SMWDIWikiPage Object' instead in SMW 1.6? getWikiPageValue(), however, seems to return for type _wpg always a SMWWikiPageValue Object and doesn't know about SMWDIWikiPage Object??? As I only submit a property name in my code and the rest are SMW 1.6 internal functions, I don't know what I can do to avoid this problem. Anything on the wiki level? Thanks, Gu On Thu, 26 May 2011 07:40:32 +0100, Markus Krötzsch <mar...@semantic-mediawiki.org> wrote: > On 25/05/11 11:20, zehetner wrote: >> Hi, >> >> regarding >>> * Type:Record declarations change: >>> Properties of Type:Record no longer take a list of types, but a list of >>> properties as their declaration (has fields). This ensures that Records >>> can use all information that is given on Property pages, not just the >>> type declarations. >> >> would there be a foreseeable problem to generate properties with the name >> of the existing field types e.g Property:string, Property:page, >> Property:number etc. to keep records functioning in the new SMW version? >> Otherwise having a rather large number of record properties it would mean >> a lot of typing to change those names in the 'has fields' declarations. > > I think this is a good idea. Would it be useful to have one builtin > property for each registered datatype? This would not be hard to do but > it would override any existing property declarations for these labels. > > Generating property pages would be a more complex process that would > need to be triggered explicitly (you cannot do this in the background on > every request). > > Regards, > > Markus > >> >> On Sun, 22 May 2011 16:10:37 +0100, Markus Krötzsch >> <mar...@semantic-mediawiki.org> wrote: >>> Dear SMW users and developers, >>> >>> work on SMW 1.6 has made tremendous progress in the past few weeks, and >>> the code is stabilizing now. We still have quite some bugs to fix ahead >>> of us, but the main changes in architecture and user features are >>> completed. >>> >>> If they have not done it yet, extension developers should now adapt >>> their code to work with the modified APIs. Audacious users are invited >>> to beta test. Installation instructions are online [1] and the SMW >>> Sandbox is updated to the most recent version [2]. >>> >>> == Main changes for users == >>> >>> * Significantly extended database backend support: >>> SMW now works with PostgreSQL and with any RDF store that supports >>> SPARQL and SPARQL Update. I had sent details about the latter to this >>> list earlier -- testers for Virtuoso and other stores would still be >>> most welcome! Support for using the PHP-based interface of the RAP RDF >>> store is discontinued. The new SPARQL functions change also prepare SMW >>> for loading RDF data from other Web sources (not implemented yet). >>> >>> * Parameter validation for user inputs: >>> The #ask function will now generate more helpful error messages if some >>> input is not suitable, e.g. if "limit" is set to "bogus" instead of a >>> number. Query printers may also use this capability for their own >>> parameters, so that even extensions can provide this validation. For >>> doing this, SMW requires the Validator extension to be installed. >>> >>> * No more "Type" namespace: >>> As discussed on these lists, the Type namespace has been removed. There >> >>> is a configuration setting that allows users to keep the Type namespace >>> enabled (so that any pages there can still be accessed). The features of >> >>> Type articles are now provided by Special:Types. >>> >>> * New Delimited-Separated Values format: >>> This is like CSV but with a sane and easy-to-parse escaping of special >>> characters. >>> >>> * Unit of measurement declarations change: >>> With the vanishing of Type pages, users who have used custom types (for >>> unit conversion) must move the text from the Type page to the Property >>> page that uses these custom types. Instead of the custom type page, "has >> >>> type" is now set to "Quantity" for properties that have custom unit >>> conversions. >>> >>> * Type:Record declarations change: >>> Properties of Type:Record no longer take a list of types, but a list of >>> properties as their declaration (has fields). This ensures that Records >>> can use all information that is given on Property pages, not just the >>> type declarations. >>> >>> * Compatibility with MediaWiki 1.18. >>> >>> * Bugfixes. >>> >>> >>> == Main changes for developers == >>> >>> There have been substantial changes to the data model: almost all uses >>> of SMWDataValue have been replaced by more lightweight SMWDataItem >>> objects. Code has been cleaned up in the process and should be much >>> clearer to understand in many places (also beyond the data item >>> changes). See my earlier email to the developer list for details. Please >> >>> ask on the developer list if you should encounter any problems updating >>> your code to work with SMW 1.6. >>> >>> >>> SMW 1.6 is an important major release for us, and a unique opportunity >>> to do some changes that are not fully compatible with earlier versions >>> (but that really improve the overall functionality and code quality). If >> >>> you have comments or bug reports, it is a very good time to make them >>> known. Some things will be much harder to change later on. We intend to >>> stabilize SMW within the next 14 days, so that a first release of SMW >>> 1.6 could happen in early June. >>> >>> Thanks to all who have already contributed to this major effort, and to >>> all who are currently working hard on upgrading their code to SMW 1.6. >>> >>> Cheers, >>> >>> Markus >>> >>> [1] http://semantic-mediawiki.org/wiki/Help:Installation_1.6.0 >>> [2] http://sandbox.semantic-mediawiki.org/ >>> >>> >> ------------------------------------------------------------------------------ >>> What Every C/C++ and Fortran developer Should Know! >>> Read this article and learn how Intel has extended the reach of its >>> next-generation tools to help Windows* and Linux* C/C++ and Fortran >>> developers boost performance applications - including clusters. >>> http://p.sf.net/sfu/intel-dev2devmay >>> _______________________________________________ >>> Semediawiki-devel mailing list >>> Semediawiki-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
