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.
And of course I'm against the current situation where FilterFactoryImpl
creates an AttributeExpression with the namespace prefixes stripped out.
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
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
> >
> > !DSPAM:1004,456deb5920521425493344!
--
Gabriel Roldán ([EMAIL PROTECTED])
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90
-------------------------------------------------------------------------
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
