Hey Gabriel;
I understand that this is a useful and quick approach; I am just concerned with
code holding on to the factory and getting confused. I know StyleBuilder holds
on to factories for example.
The other source of confusion; which Niels has been trying to help me with; is
straight up disbelief that XPath is not namespace aware (ie the string
representation should be able of having namespace information as part of the
xpath).
I expected someone to be able to write an xpath expression that would contain
namespace information ... let us see if that is possible.
It looks like JXPath is capable:
http://commons.apache.org/jxpath/users-guide.html#Registering_Namespaces
Looks like JXPath works on expanded names; and to take advantage of that when
working with objects a custom NodePointer is needed (bleck more work than I
expected):
> Namespaces do not apply to objects, unless, of course, those objects are
> handled by
> custom NodePointers that are made namespace-aware. The standard distribution
> of
> JXPath does not contain any such NodePointers. As far as the interpretation
> of XPaths
> on XML documents is concerned, we are bound by the XPath 1.0 standard.
> On the other hand, the standard does not say anything about applying XPaths
> to any
> non-XML object models, therefore we were free to make pretty much arbitrary
> choices.
> One of those choices was to ignore namespaces.
As for "remapping" the XPath expression - I understand that unpacking that
string; and adjusting/remapping to reflect the expectations of another context
would be a pain - but I was hoping JXPath would have a parser and data
structures to help with that - that far I have not had much luck. Looks like
they are using JavaCC for the heavy lifting and have hidden internal data
structure away.
There is the "reference implementation":
Reference implementation of JXPath. It comes with a JavaCC-based parser for
XPath expressions, a parse tree and a fast interpreter, which applies XPaths to
graphs of Java objects.
So perhaps you could get access to the parse tree and have a hack in order to
"remap" XPath expressions.
Jody
On 12/12/2010, at 3:23 AM, Gabriel Roldán wrote:
> Hi all, sorry this turned out to be a long mail.
>
> I just read the latest messages on this thread from yesterday but had to
> back track from start up to this one to see why you're looking for an
> alternative to FilterFactoryImplNamespaceAware.
>
> As per Justin's concern of making it part of core but optional, and
> strictly speaking of GeoServer's usage of FilterFactory, I see no reason
> why not to make it the default one, provided it's a prototype spring
> bean. Reason is that it adds _no complexity_ to the normal usage of
> FilterFactoryImpl. If you use it's setNamepaceContext method, then it'll
> pass in the namespace context to the PropertyName as a hint, otherwise
> it does nothing different than FilterFactoryImpl. It is also non
> invasive for PropertyName, since as it gives the context as a hint,
> PropertyNameImpl will lookup for PropertyAccessors using the hint only
> if available, so no change for usual behaviour.
>
> As per the convention on factories being stateless, that still holds
> true for any place where you don't need an evaluation context and no
> code shall be changed in those places. But when you need it it'll just
> solve your life and if its configured as a spring prototype its as cheap
> to be created as an Integer, then you can set the namespace context
> provided by the request. Some OGC requests explicitly account for that,
> like in WFS's DescribeFeatureType with the namespace parameter. XML
> request do too, as they declare the prefix mappings and may differ from
> the "official" ones the server knows about.
>
> IMHO, property names should keep being a String representing an XPATH,
> or you will not be able to use indexed property access to multivalued
> nested properties in your SLD's. For example, if you want to make a
> decision to apply one symbolizaer or another based on the value or
> existence of the "myns:MyFeature/gml:name[2]" xpath.
> And all of those already works properly using the standard geotools
> evaluation criteria (property accessors) and modelling XPath as strings,
> as in the specs. The only option will be to set up a more complicated
> data structure to model the location paths including indexes and
> attributes and an alternate evaluation mechanism. Instead, we can just
> set the factory's namespace context in the places where it makes sense
> (when parsing the namespace parameter for DescribeFeatureType, or after
> parsing an XML POST request and getting the prefix mappings out of it).
> Anything else keeps untouched, as the client is required to either use
> the naming supplied by the server (for example, through getcaps or DFT
> response), or explicitly state the namespace prefix mapping if deviating
> from that.
>
> Also not (E)CQL also allows the creation of nested location paths for
> property names (e.g. "prop1.prop2.prop3"). It even provides an
> overloaded version of toFilter and toFilterList that receives the
> FilterFactory to use.
>
> My 2c.-
>
> Gabriel
>
> On Fri, 2010-11-26 at 11:11 +0800, Niels wrote:
>> Hi Justin and everyone,
>>
>> All what FilterFactoryImplNamespaceAware does, is creating
>> AttributeImpl objects with the NameSpace information written in its
>> hits. These hints are then picked up by the FeaturePropertyAccessor
>> (also defined in app-schema) who can evaluate properties with
>> namespaces.
>>
>> I think what needs to happen is this.
>> The basic FilterFactory interface (and its impl) should support
>> creating properties with namespace information in their hints
>> (optionally). This is only a change of a few lines of code. The only
>> concern here is, that prefix:namespace mappings can be different per
>> request or per file being parsed. As a consequence, we cannot keep
>> using one single filter factory throughout the system, but rather need
>> to create different instances depending on namespace information, and
>> the classes pass them ( optionally) on to each other; the good thing
>> is that the support to pass on filter factory instance seems to
>> already exist in many classes.
>>
>> In any case, there wouldn't be any need to build namespace support
>> everywhere overnight, since it remains an optional configuration
>> option. Namespace support can be built in gradually, I can start with
>> where I need it now (WMS) without hurting any other part of the
>> system.
>>
>> Also, optionally, we could merge the classes FeaturePropertyAccessor
>> and XPathPropertyAccessor in to one, because these are basically doing
>> the same thing. It wouldn't be necessary for it to work, but it would
>> be a performance improvement.
>>
>> Regards,
>> Niels
>>
>> On 25/11/10 23:23, Justin Deoliveira wrote:
>>> Hi Niels,
>>>
>>>
>>> You are correct, handling namespaces properly everywhere is a
>>> mountain of work. Unavoidable side affect of geotools being
>>> originally designed for simple features.
>>>
>>>
>>> However I totally agree that moving the NamespaceAwareFilterFactory
>>> into the core is a good place to start. And allow particular
>>> subsystems (like rendering) to gradually support complex features.
>>> What is involved in moving the class over? Does it have any
>>> dependencies on app-schema stuff? Or is it pretty much standalone?
>>>
>>>
>>> I think you are on the same page but I think it is important to make
>>> the namespace aware filter factory optional... and not have it be
>>> the default.
>>>
>>>
>>> 2c.
>>>
>>>
>>> -Justin
>>>
>>> On Wed, Nov 24, 2010 at 10:39 PM, Niels <[email protected]>
>>> wrote:
>>> Hi,
>>>
>>> I am currently working on making WMS work with complex
>>> features.
>>>
>>> One of the main problems I am currently encountering, is
>>> that the filters built from the SLD file are not working
>>> when applied in the renderer, because the attributes inside
>>> them are x-paths, and they can't be properly evaluated
>>> against the features.
>>>
>>> However, I know that they would be evaluated perfectly if a
>>> NameSpaceAwareFilterFactory (from app-schema) was used
>>> instead of the default FilterFactory, correctly configured
>>> with the prefix/namespace mappings provided by the user. So
>>> in fact the implementation to evaluate these filters and
>>> expressions properly already exists in the system, it is
>>> just not being used! And there are some other side issues
>>> related to the same problem, like for example, testing
>>> whether the attributes provided in the style really exist
>>> for proper error reporting, etc... Of course we are talking
>>> about code in the render and main packages, which aren't
>>> aware of app-schema.
>>>
>>> I think namespace support should not be a specific
>>> app-schema thing, but something provided through the system.
>>> Everywhere in the code I see hacks where namespaces are
>>> actively thrown away, which is effectively causing bugs when
>>> people have different properties with the same local name
>>> but different namespaces, which should be supported. (see
>>> also
>>>
>>> http://old.nabble.com/WFS-1.1-GetFeature-Attribute-missing-in-2.1-td30207470.html)
>>>
>>> Why not move the implementation for the namespace awareness
>>> from app-schema to the core of geotools, and allow the
>>> commonly used filterfactory to be configured with namespace
>>> support?
>>>
>>> I think this is the main milestone that needs to be reached
>>> before WMS can support complex features. In fact I am pretty
>>> sure it is the only issue that needs to be resolved, and it
>>> seems almost impossible to work around it. And it would get
>>> rid of some buggy behaviour!
>>>
>>> --
>>> Niels Charlier
>>>
>>> Software Engineer
>>> CSIRO Earth Science and Resource Engineering
>>> Phone: +61 8 6436 8914
>>>
>>> Australian Resources Research Centre
>>> 26 Dick Perry Avenue, Kensington WA 6151
>>>
>>>
>>>
>>>
>>> --
>>> Justin Deoliveira
>>> OpenGeo - http://opengeo.org
>>> Enterprise support for open source geospatial.
>>>
>>>
>>
>>
>> --
>> Niels Charlier
>>
>> Software Engineer
>> CSIRO Earth Science and Resource Engineering
>> Phone: +61 8 6436 8914
>>
>> Australian Resources Research Centre
>> 26 Dick Perry Avenue, Kensington WA 6151
>>
>> ------------------------------------------------------------------------------
>> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
>> Tap into the largest installed PC base & get more eyes on your game by
>> optimizing for Intel(R) Graphics Technology. Get started today with the
>> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
>> http://p.sf.net/sfu/intelisp-dev2dev
>> _______________________________________________ Geotools-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
> --
> Gabriel Roldan
> [email protected]
> Expert service straight from the developers
>
>
> ------------------------------------------------------------------------------
> Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
> new data types, scalar functions, improved concurrency, built-in packages,
> OCI, SQL*Plus, data movement tools, best practices and more.
> http://p.sf.net/sfu/oracle-sfdev2dev
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
