Hi again, sorry for the long wait. I have been working on some slightly
easier tasks for the time being, but have now returned to this :) So, i'm
still having issues where when querying the data from the #ask parser is
not showing any data (empty table cell). Please take a look at the polygons
branch on SMW and SM if you have the time. But anyways, back to the
response i recieved from you.
> Did you register your new datatype (DV class) to use containers? This is
> done in the hook smwInitDatatypes; see SMW_DatavalueFactory for
> docuemntation (it's similar to the property registration, using
> registerDatatype and registerDatatypeAlias). Without this, SMW won't know
> that you need a container and it will just give you the subobject (wikipage
> DI) when retireving data from the store; this would then be rejected by
> your DV, and no values would be created.
>
Yes i believe i have so, i have registered the datavalue through calling:
SMWDataValueFactory::registerDatatype( '_gpo', 'SMGeoPolygonValue',
SMWDataItem::TYPE_GEOPOL );
in the SemanticMaps extension which is in a method that is called on the
smwInitDatatypes hook.
In the SemanticMediaWiki extension i have registered through adding:
'_gpo' => SMWDataItem::TYPE_GEOPOL, // Geographical polygon
to the self::$mTypeDataItemIds array in the function initDataTpes in
SMWDataValueFactory.
Is there anyway i can verify if i have registered this datavalue properly?
for example adding a breakpoint to a method that SMW would call in the
datavalue?
>
>
> Now for the first issue (which may not be your problem yet, but will
> probably come up later). Container-type data values need to be queried
> differently. Every datavalue has its own code for deciding what to query
> when a user enters some string in #ask. This is implemented in the
> SMWDataValue's method getQueryDescription(). The default handling is to
> interpret initial comparators (<, >, ...) first, and then parse the rest
> like a user input. The result is used for querying. This does not work for
> containers, since, IIRC, SMW does not currently support the use of
> container DIs in queries (i.e., in the PHP level description of queries). I
> might be wrong here.
>
So far i have just added a stub method getQueryDescription in the datavalue
class, however it's not being called (yet), however i'm guessing that is
because of my issue above.
>
> The pedestrian solution for now is to implement something like in
> SMW_DV_Record.php. The code there has two modes during parsing: either
> construct a DIContainer or construct a query description. This is actually
> needed there because Records also support comparators (<, >, ...) for
> *each* of their component values in queries; so the parsing is sightly
> different (it must allow comparators in front of each value, not just at
> the very beginning). If this is not desired, then one could also have the
> same parsing and just turn the container into a query (this might already
> have code somewhere; not sure). The only thing to do differently would be
> to use an anonymous subject for the Container in this case -- otherwise the
> query will search for exactly the subject name that you have given, which
> is not correct.
>
I will have to get back to you on this one when i get that far.
>
> This thread is getting into the most comprehensive documentation of SMW
> internals ever written ;-)
>
> Markus
>
Cheers.
Kim
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
