Gabriel Roldán wrote:
> I would say that PropertyName being a simple String could be just ok as far
> as
> it is an expression, but we lack context to be able of correctly evaluating
> it
> Instead, I would propose:
>
> CommonFactoryFinder.getFilterFactory(NameSpaceSupport)
>
> or whatever construct we use to map prefix/namespace
>
> That should return a namespace aware FilterFactory, in the same sense that
> you
> can ask a DOM for an xpath in a namespace aware way or not.
>
> side effect of this would be the need to pass the NameSpaceSupport to
> PropertyAccessor, but I think that would make sense after all.
Interesting approach, I never thought of that, good idea!!
>
> And of course I'm against the current situation where FilterFactoryImpl
> creates an AttributeExpression with the namespace prefixes stripped out.
Very much so.
>
> So PojoPropertyAccessor would always strip out the prefixes,
> FeaturePropertyAccessor would act depending on wether the expression has or
> not prefixes, like returning both gml:name and myns:name for /name, and just
> myns:name for /myns:name, with the prefix substitutions mandated by the
> NameSpaceSupport map
This one will be easy to pull off with the new feature model for sur.
>
> 2 cents
>
>
> On Wednesday 29 November 2006 22:54, Justin Deoliveira wrote:
>> 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
>>>
>>>
>
--
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
