Paul, I have some quick comments. First let me say that I think the concept you propose is an intersting one, and that I'm not dismissing it entirely. However, I have a couple of conerns and/or questions.
My first concern is about simplicity. I know we are adding some great styling functionality here, but we are also adding more complexity for the end user. I think this is caused in part by some confusion among our project about the purpose of a Layer or Layerable object. For example, the Javadoc for the Layer object contains this description: "Adds colour, line-width, and other stylistic information to a Feature Collection." This indicates to me that the main purpose of a Layer is to control the style and appearance of Features contained in the Layer. If we want to stick to this principle I would say that, drawing from your example, that Churches should be put on their own Layer, and Schools on their own Layer, instead of sharing a Layer. I realize this places a limitation on design, because Churches and Schools really share a common set of attributes defined as a "building". To me the solution is to relate Features in the Schools and Churches Layer to a non-spatial table called GenericBuildings or something similar. I think we all need to get together to decide what the purpose of a Layer will be and what restraints we want to place on messing with the Layer classes in the core. I blogged about this not to long ago: http://openjump.blogspot.com/2007/06/organizing-features-in-openjump.html This is a very important question because it will determine where our particular project will strike the balance between simplicity and functionality. Can you give us a couple of days to discuss your changes? I'm not saying that it shouldn't go in the core, I'm just saying we need to think carefully about it. Will we continue to allow these types of changes with a murky definition of a Layer object and its purpose? How complex do we want OpenJUMP to get? It is not my place to lay down laws in this regard, I'd like us all to make a decision on this together. I also would like you to strongly consider including this functionality in a plug-in, instead of using modifications to the core. I believe this would be technically possible based on the description you provided. Can you take a look at your design and see how it might be implemented as a plug-in? If everyone loves how your plug-in works we can then modify the core. Still, I will strongly encourage you and any other OpenJUMP developer to use plug-ins whenever possible. In my humble opion we should only modify the core to enable more extendability, not to add functionality. Additional functionality should be implemented with plug-ins. Let's see what the other developers say. Most of them will usually disagree with me. :] Please keep up the good work. I realize some of the challenges you face in OpenJUMP development are caused by our lack of a firm vision for what OpenJUMP should be. Please exercise patience with us. The Sunburned Surveyor On 6/27/07, Paul Austin <[EMAIL PROTECTED]> wrote: > At the moment the Task frame has two levels, Category and Layer. I would > like to propose a third Theme. > > What is a theme? A theme identifies a sub set of features in a Layer > which have their own style, a label and you can show/hide the layer. > > For feature layers an example would be a building you may have schools > and churches that are rendered using different symbols. This corresponds > to the ColorThemingStyle. > > For WMS layers you could use themes to represent each layer from the > server, with the icon being the legend graphic from the server. Here > when you show/hide a layer it would add or remove that layer from the > WMS request and update the layer. > > To support this we would need to add a new Theme interface to the > workbench.model, which describes the theme. Different type of Layerable > would use their own implementations of this interface. > > public interface Theme { > String getLabel(); > > void setLabel(String label); > > BasicStyle getStyle(); > > void setStyle(BasicStyle style); > > boolean isVisible(); > > void setVisible(boolean visible); > } > > I would also propose a ThemedLayerable interface that would allow you to > get the themes for the layer, Layerables that support themes would > implement this interface. > > public interface ThemedLayerable extends Layerable { > public List getThemes(); > } > > Would would then need to modify the LayerTreeModel and the > TreeLayerPanel to support this new kind of item in the tree. > > For Layers I would delegate getting the Themes from the Styles, and my > new FilterTheming style would use this. > > I almost have this code ready to checkin, I'll post a diff so that > people can have a look at what I've done and decide if this is something > we should add to the core. > > Paul > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
