Hi Andrea: A small update on this one - I have focused the last week on improving the uDig style editing story. And have turned up not one; not two; but three helper classes all of which fall into the roll of a "Builder" for style.
I am collapsing them all into one right now; now while it is not going to quite meet my standards of what literate programming means - the result should be useful. It operates as a true "Builder" wrapping around a Style and assisting normal programmers in working on it. As it stands right now the class SLDContentManager focuses on letting people work safely on the "default" featureTypeStyle; and supports look up of featureTypeStyle and Rule by name. SLDContentManager builder = new SLDContentManager( style ); // focused on FeatureTypeStyle named "default" out of the box Rule rule = builder.getDefaultRule(); // will grab the default Rule rule = builder.createRule( "john" ); // create the rule John - and adding it to the current feature type style If you like you can create multiple SLDContentManager on the same physical Style object; they only maintain state in order to help edit and avoid all the annoying for loops and null checks. This is something we could not do when working on immutable data structures like SimpleFeatureType. Talk to me when you come back from Holiday; and I can copy this class to GeoTools if you are interested (although I hate the name on this one). Jody On 13/06/2009, at 6:13 PM, Andrea Aime wrote: > Hi all, > many years ago pissed off by how hard it was to build > styles with code I created the StyleBuilder we have today... > shame on me :) > > Now, I would like to propose a new style builder to replace > that old clunky one. I would like it to be very compact, > chock full of default behavior, and fluent. > This mail just strokes out the general ideas, it's not > a full fledged spec of how it would look like. > > A OGC Style is structured as a tree: > > Style -> FeatureTypeStyle* -> Rule* -> Symbolizer* > > Now, one could make a tree of builders, but that would > mean the user would deal explicitly with 4 builders and would > have to compose the results... ugh, better write the > SLD by hand and parse it ;-) > > The idea to simplify the above would be that: > - there is one main builder that allows access to > all the child ones with a fluent api > - at every moment, there is only one style, one > FTS, one rule and one symbolizer being built. > When you say you want the symbolizer, it's the > current one > - the only thing you're actually forced to specify > is a symbolizer. Everything else is defaulted > and assumed to be around (no need to actually > make calls to create a fts or a rule). And we > could even default the symbolizer itself (if > you did not say anything about it, it's a default > point style). > - when a higher level object is built, it cascades > the build to the contained objects being built > - when a new object is started, the previous one > is accumulated and will be used when building > the upper level object > > Some ideas of how the api might look like, builder > orchestration wise: > StyleBuilder -> the current styleBuilder > StyleBuilder.fts() -> the current feature type style builder > StyleBuilder.rule() -> the current rule builder > StyleBuilder.symbolizer() -> the current symbolizer builder > StyleBuilder.startFTS() -> starts a new feature type style, > accumulates > the previous one, if any > StyleBuilder.startRule() -> starts a new rule, accumulates the > previous > one if any > StyleBuilder.startPoint() -> starts a new point symbolizer, > accumulates > the previous one if any > StyleBuilder.startLine() > StyleBuilder.startPolygon() > StyleBuilder.startRaster() > > > Some examples of how it could be used: > > // builds a default point style > StyleBuilder sb = new StyleBuilder(); > sb.startPoint(); > Style ps = sb.buildStyle(); > > // builds a default polygon style > sb.startPolygon(); > sb.build(); > > // builds a blue 2px line style > sb.startLine().stroke(Color.BLUE).strokeWidth(2); > sb.build(); > > // a default polygon style with a filter and min scale > sb.startPolygon(); > sb.rule().filter(myFilter).minScale(minDenominator); > sb.build(); > > // simple two color thematic map > sb.rule().filter(filter1); > sb.startPolygon().fill(Color.RED); > sb.startRule().filter(filter2); > sb.startPolygon().fill(Color.YELLOW); > sb.build(); > > // highway style line with two overlapping fts > sb.startLine().stroke(Color.WHITE).strokeWidth(3); > sb.startFTS(); > sb.startLine().stroke(Color.GRAY).strokeWidth(1); > sb.build(); > > build() method wise, I was thinking each nested builder > would show the same method. When called it builds the current > object and resets it along with the lower levels. > So for example sb.rule().build() would cascade to the > current symbolizer, accumulate all the symbolizers found, > and reset both the rule and the symbolizers states. > But the most common case would just to call the top > level build() object to get a full fledged style. > > What do you think? Am I on to something? > Cheers > Andrea > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
