On 30/05/11 11:48, zehetner wrote: > 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 for the report. The code on SVN (r89217) has now been fixed to avoid this problem. Note that SMWPropertyValue::makeUserProperty($propname) should only be used if the input $propname is indeed some (possibly messy) user input. If the name of the property comes from a reliable source, then you can also format it as a DB key (replace ' ' by '_') and use "new SMWDIProeprty($dbkey)" to get an SMWDIProperty object right away (in this case, findPropertyTypeId() is called to get the type id). But for user input SMWPropertyValue is the right way to go. Cheers, Markus > > 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 >>> > ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
