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
