Hi,
for record properties I get from $property->getPropertyTypeID() the type
__err back
and this function in includes/datavalues/SMW_DV_Property.php looks
strange:
/**
* Convenience method to find the type id of this property. Most
callers
* should rather use SMWDIProperty::findPropertyTypeId() directly.
Note
* that this is not the same as getTypeID(), which returns the id
of
* this property datavalue.
*
* @return string
*/
public function getPropertyTypeID() {
if ( !$this->isValid() ) {
return $this->m_dataitem->findPropertyTypeId();
} else {
return '__err';
}
}
shouldn't it rather be
if ( $this->isValid() ) {
instead of
if ( !$this->isValid() ) {
Gu
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. 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
