> 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.
Why is that needed; we have a compound Name object used for Attribtues? Oh wait are you meaning the Property filter... > The basic FilterFactory interface (and its impl) should support creating > properties with namespace information in their hints (optionally). We should be able to create a Property filter with a complete Name (rather than a String) and thus store the namespace information). Are you sure this is not already possible? > 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 > > ------------------------------------------------------------------------------ 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
