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
> <[email protected]> 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
>>> <[email protected]> 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
>>>>> <[email protected]> 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
>>>>>> [email protected]
>>>>>> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
