On Sat, Apr 28, 2012 at 8:05 PM, Justin Deoliveira <[email protected]>wrote:
> Right, my point is to look at what it takes to build a filter with
> straight factories. Take a relatively non complex filter:
>
> FilterFactory2 factory = (FilterFactory2)
> CommonFactoryFinder.getFilterFactory(null);
>
> PropertyIsLike f1 = factory.like(factory.property("name"), "*roads*");
> Intersects f2 = factory.intersects(factory.literal("latLongBoundingBox"
> ), factory.literal(new Envelope(-180,-90,180,90)));
> Filter f = factory.and(f1, f2);
> I mean is it doable, yes. It is convenient, imo no. What I would long for
> is something like:
>
> Filter f = new FilterBuilder().like("name", "roads").and().intersects(
> "latLonBoundingBox", new Envelope(-180,-90,180,90))
>
Yep, that would be better. I tried to start going down that path when I
made the StyleBuilder, but it was not that easy because
of how the filters are nested.
In style builder I could break out a tree of builders so that you could
build a complex style without having to get crazy
and going up and down the nesting with a single builder call chain (though
the single builder call chain is
available for simple styles. See the following:
RuleBuilder rb = new RuleBuilder();
rb.point().graphic().size(6).mark().name("circle").fill().color(Color.RED);
TextSymbolizerBuilder tb = rb.text().label("name");
tb.fill().color(Color.BLACK);
tb.newFont().familyName("Arial").size(12).styleName(Font.Style.NORMAL)
.weightName(Font.Weight.BOLD);
tb.pointPlacement().displacement().x(0).y(5);
tb.pointPlacement().anchor().x(0.5);
Style style = rb.buildStyle();
However I was not sure how to do something like that with Filter,
where the level of nesting is quite a bit
higher and less predictable (thining about handling and/or, nested
expressions and function calls).
Well specific enough that you need most of the geotools library to be able
> to use it, but yes not a problem for geoserver. And I can't imagine the non
> feature case is really battle tested at the point that there are literally
> zero assumptions about feature objects. But those are implementation
> details, to be dealt with later.
>
Yep, agree that the current property extractors can be lacking. Something
that either BeanUtils (if we want to stick
with the a.b.c[3].f notation) or some xpath support should handle for sure
(again, for example, JXPath,
http://commons.apache.org/jxpath/users-guide.html)
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
