> I was exploring a little more this task, and came along with some other > questions: > > 1. How can we effectively use StyleFactoryImpl2? > - SEParser and DuplicatingStyleVisitor currently expect an > org.geotools.styling.StyleFactory interface, which DOES NOT have the new > factory methods. Do you think there should be a StyleFactory2 interface?
Two ways: - replace the SEParser field with an org.opengis.style.StyleFactory - change StyleFactoryImpl to delegate to the StyleFactory2 implementation (since we cannot do multiple inheirietence). > - In this case, should we add a CommonFactoryFinder.getStyleFactory2 method, > as was done with the FilterFactory case, so that classes such as > DuplicatingStyleVisitor can instantiate it? CommonFactory interface is no longer available; it was part of the go-1 specification that has died a painful death. As such the code now uses BasicFactoryFinder (or whatever the implementation was called). \I am going to be tempted to break out a StyleFactoryFinder class (so we can be consistent for all our factories). I was going to talk to Michal Bedward about this; since we are documenting up some of this stuff for a tutorial. And I would kind of like to base my decision on the readability / consistency of the resulting code. > 2. How should we deal with default values / initialization of symbolizer > parameters (e.g., stroke, uom, etc)? > - Current practice is to initialize everything to null by default, and the > getter methods simply return null in that case (I find this a little strange, > by the way) I would like to provide them some how - the options are: - bake them into the SLDParser; this is actually a reasonable option since the SLD specification indicates what the assumed values should be. The SLDParser can take responsibility for filling in these assumed values when it creates the various style objects. This is nice in that it gives us a way to allow SEParser and SLDParser to assume different values (if the two specificaitons actually differ). - bake them into the StyleBuilder (builders are allowed to hold state and have logic and other wise "help" you build a useful style). It is only when both builder and factory have logic that we get really insane situtations where you cannot tell what has been produced. > - Should we change that to return default values in the getter methods > whenever the parameter is null? I had considered this; but I hate magic values. In this case I would rather the renderer assumed a default value if the width for example was an Expression.NIL. (I try and use Expression.NIL, Filter.INCLUDES, Filter.EXCLUDES where possible rather than "null" ). > - Should StyleFactoryImpl2 set default values for null parameters? No - the factory needs to have no logic. Logic can be in a parser or builder. > - Should we not accept null values in the initialization? I think it would be fair to throw a null pointer exception; or allow null to be stored depending on what the javadocs say (I would rather Expression.NIL be used of course). > Aside from that, I implemented a little Enum class for storing the OGC > definitions for UOMs (both the String expected in the .sld file and the > corresponding Java Unit). Do you want to take a look? (attached) That sounds fine; I seem to recall someone else doing this recently (in order to get around UOM for the WPS specification; so there is a chance we could have a single utility class for this). ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
