Thanks Markus!

Sorry if I didn't make it clear, the reason why I got __err back was the
erroneous '!' in the mentioned function (although I'm now not sure why none
record properties seemed to work even with the bug?). 
Anyway in the corrected version all work fine.

Cheers,
Gu

On Wed, 01 Jun 2011 17:14:26 +0100, Markus Krötzsch
<mar...@semantic-mediawiki.org> wrote:
> On 01/06/11 10:05, zehetner wrote:
>> Hi,
>>
>> for record properties I get from $property->getPropertyTypeID() the
type
>> __err back
> 
> That should not happen. I suppose that your type declaration for such 
> properties reads "[[has type::Record]]". If this is stored correctly, 
> you should get the ID '_rec' as a result. This type is no longer handled

> in a special way in SMW. so I don't know why it would return an error.
> 
>> and this function in includes/datavalues/SMW_DV_Property.php looks
>> strange:
>>
> ...
> 
>>
>> shouldn't it rather be
>>
>>                  if ( $this->isValid() ) {
>> instead of
>>                  if ( !$this->isValid() ) {
> 
> Yes! Changed in SVN now.
> 
> Markus
> 
>>
>> On Tue, 31 May 2011 16:02:37 +0100, Markus Krötzsch
>> <mar...@semantic-mediawiki.org>  wrote:
>>> 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. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel

Reply via email to