Jody Garnett wrote:
> Justin Deoliveira wrote:
>> Jody Garnett wrote:
>>> The GeoAPI interface should already have a method that accepts Name
>>> class (ie namespace plus localpart). You can choose to store both in our
>>> implementation and do as you see fit.
>>>
>> I don't think so. PropertyName is just an xpath expression, which may
>> have multiple namesapces / local parts associated with it. A single
>> name wont do it. I also see no such thing on the PropertyName interface.
> So you need the raw xpath alone then - it includes the information you
> want?
Yeah, i need to run the full xpath expression (as is ) against the
object, like we did on the complex features branch.
>>> If your GMLDataStore knows about such things as namespace you can
>>> make a special PropertyAccessor just for it that takes everything
>>> into account.
>> Unfortunatley creation occurs at parsing time, and the parser has no
>> notion of a special datastore of sorts. To pull this off I would need
>> to be able to register PropertyAccessor instances dynamically at
>> runtime, which isn't really possible with our extension mechanism.
> So we need to follow our own guideline of "injecting" these sorts of
> thing - to make the Filter evaluation context aware? Or is this a use
> case for Martin's might morphing power Hints?
>> Also, the information needed to pull this off is only available while
>> the filter is being parsed. It isn't really around at evaluation time,
>> so hints wont really work either.
> Nasty; is their anyway Filter can take this information along for the
> ride? I see in your original request you talk about picking up all the
> namespaces available during parsing; can you show a code example about
> what that would do to our poor Filter api?
If we were to solve this with hints or context it would mean that the
application calling the parser would have to manage namespace
registration/state, this would get pretty messy.
All xml bindings have access to the current namespace context, so the
binding for property name looks like this.
class ProperyNameBinding {
NamespaceContext context;
ProperyNameBinding ( NamesapceContext context, FilterFactory
factory ) {
this.context = context;
this.factory = factory;
}
Object parse( Node node ) {
String xpath = node.getText();
return factory.property( xpath );
}
}
What I would like to do is this:
Object parse( Node node ) {
String xpath = node.getText();
return factory.property( xpath, namespaceContext );
}
Other options:
1. Create my own implementation of PropertyName.
2. Depend directly on FilterFactoryImpl ( or some other extension of
geoapi FilterFactory) in the PropertyName binding and add the
appropriate method to it.
>
> I am in conflict here:
> - I would like to preserve the separation between query model (filter)
> and metadata model (schema) if we possibly can;
> - I hate turning things into objects and having them forget all the
> stuff available during parsing (as in this case it comes in useful).
>
> Straight up conflict; so I guess I need to know more... my slight hope
> is that the parser can be "greedy" and use the namespace information it
> has to disambiguate the property expression during the parse...
I dont think I can do this. The parser has now idea how the xpath
expression will be used so there is no way it can mutate it into
something the feature model can understand.
> Jody
>
> !DSPAM:1004,456deb5920521425493344!
>
--
Justin Deoliveira
[EMAIL PROTECTED]
The Open Planning Project
http://topp.openplans.org
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
