I've been staring at the code now for the past few hours, and i simply cant
figure out why my data isn't retrieved. Unless i can get some more support
on this then i'm afraid i will have to seize my plans on extending SMW with
polygons, circles, rectangles, and lines datastructures.
But i reckon if i can just get polygons to work 100%, then it would be
fairly easy for me to implement the rest.
Polygons and lines have the same structure, so they should be implemented
the same way.
Circles and rectangles have two parameters instead of an unknown number, so
they would act much in the same way as todays geographical coordinate.
So i guess the question is, can either of you, or maybe both (Jeroen and
Markus) take a look at the code under the branch polygons, and see what you
make of it. Is there something missing? Am i using the container structure
in a way that is completely and utterly wrong? Have i managed to register
all the hooks that i need so that datavalues are loaded properly? ++++
Kim
On Tue, Jun 12, 2012 at 10:13 AM, Kim Eik <k...@heldig.org> wrote:
> 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
