Hi guys; I would like to make sure FeatureTypeStyle and below are immutable; this is the part we actually feed into a portrayal engine; and it makes sense to address thread safety etc up front. If the rendering implementations can trust the style not to change they can be coded in a much more effective manner. I had already removed the event handling from GeoTools trunk; it was not used by anyone and made the code impossible to maintain.
Now for this idea to work we need to define a good style builder; the kind where you can load an existing style in; manipulate the data structure and produce a modifed copy. You may also of seen some requests on the user email list asking if we are insane; asking us to turn these things into a mini DSL; where the style objects know enough to create their children etc... This would be nice for users; and it is something that can be done as an implementation option; but should not effect the contract between Style and a Renderer. Remember the factory classes are intended to have all the parameters; if you want a simple bit of code that performs logic (even if the logic is providing defaults) put it into a builder. Jody johann sorel wrote: > Hello, > > I would like every PMC opinion on this. > > I'm working on a branch for style and I arrived at the Symbolizer level. > > > Martin raised this issue of GeoAPI when I started to work on the new > style interfaces. > "Should we make Styles Immutable ?" > > Here is the structure of the style interfaces : > Style > FeatureTypeStyles > Rules > Symbolizers > Parameters (to simplify) > > What I propose is to make Symbolizer and underneath classes immutable. > Doing this will bring several advantages : > - Thread safe > - Less memory consumption (we reuse objects) > - Simplify code > - Enable more efficient Cache for renderers > - Events handling, no more fine grained changes > > I have choosen the Symbolizer because it's the style element > that stores all portraying informations. If the symbolizer is immutable > it will enable better multithreading in renderers. > > > Andrea raised some concerns: > - Inconsistency : we only have half of the style classes immutable. > > - Factories with too long methods : if we make symbolizer immutable we must > provide creation methods with all parameters. > > Solution : add methods in the factory with less parameters. an exemple > is provided > in the GO module class : org.geotools.styling2.SymbolizerBuilder. > > > regards > > ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
