Larry wrote: "I still don't see a use for this system." This means one of two things. Either I didn't do a good job explaining it, or I'm a really crappy programmer.
Maybe it is a little of both. Can you customize the rendering of any implementation of Layerable using a Style? What if you want to add support for rendering of something like images or other raster data? Could that be done with a style? I don't know that extending WMSLayer would allow you to customize rendering behavior, but maybe I chose a bad example. Here is my plan for using the pluggable rendering system. I want to add support for stand alone map labels/text entry. Could you do this with a style? I am curious what you think. I know you and the others have a lot more programming experience than I do. I'm basically taking part of the rendering system and making it modular. Maybe it was already modular with Styles? I'll have to take a look at the Styles class. I hate to think that I wasted all of this work... Maybe Jon, Martin, or Sascha or someone else with knowledge of JUMP's rendering system can comment. I welcome suggestion on how to refine the design of pluggable rendering system so that it is useful, or maybe it needs to be abandoned altogether... Thanks for the input. The Sunburned Surveyor On 7/26/07, Larry Becker <[EMAIL PROTECTED]> wrote: > Hmm, it appears to me that your first example would be better served > by extending WMSLayer, and the second should be done with a Style, but > it would not work for my example. I still don't see a use for this > system. > > regards, > Larry > > On 7/26/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > > Larry, > > > > The original JUMP only allowed you to customize rendering behavior for > > objects that were painted above and below the Layerable objects. In > > addition, the programmer had no control over the order these > > "non-layerable" objects were painted in. > > > > The first restriction was partially addressed by Ole Rahn. (I think it > > was Ole, anyways.) He hardcoded into the RenderingManager different > > rendering behavior based on the class of Layerable being painted. In > > this case he I believe he enabled different painting logic for > > WMSLayer objects than for regular Layer objects. (Or maybe he was > > doing the custom painting for image layers. I don't remember at this > > point.) > > > > I was intrigued at the idea of allowing different rendering behavior > > based on the class of the Layerable object being rendered. My goal was > > to allow this behavior via a plug-in, instead of OpenJUMP's current > > system which was based on hardcoding the "switch" logic to select the > > appropriate renderer into the RenderingManager class. I basically > > tried to take Ole's switch logic and make it pluggable or modular. > > > > I did this by implementing the State design pattern. I created a > > RendererFactory class that returns the appropriate renderer when given > > the Layerable object that needs to be painted. We will now be able to > > customize the rendering of any Layerable object by simply dropping a > > JAR file into the /ext directory. > > > > Here is one example of how this might work. Let's say I design some > > logic that I think will really speed up the rendering of WMSLayers in > > OpenJUMP. I simply encapsulate my renderer in a plug-in and add it to > > the /ext folder. OpenJUMP will now render all istances of the WMSLayer > > class with my new renderer, instead of the built-in renderer. There > > will be no need to recompile OpenJUMP's source code. > > > > This pluggable rendering system will also allow us to add rendering > > behavior for new Layerable objects. Here is an example of how this > > might work. Let's say I want to add support for route and route > > stationing to OpenJUMP. I design a set of classes to support this > > behavior, one of which is a RouteAlignment class. This is a linear > > feature that needs to be painted on the screen with stationing labels. > > I can make a new class that implements the Layerable interface, > > something like AlignmentsLayer, and then create a renderer that will > > only paint instances of that class. > > > > I have also added the ability to control the order that > > "non-layerables" are painted above and below the Layerable objects. > > > > I hope these changes will be of use to programmers like Geoff, who > > like developing with plug-ins, but who don't want to mess with > > building the core. > > > > My changes to existing code are mostly in the RenderingManager class. > > I had to tweak the behavior of the getRenderer and createRenderer > > methods. Everything else basically stayed the same. > > > > I hope this rambling makes some sense. > > > > The Sunburned Surveyor > > > > On 7/26/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > > Hi SS, > > > > > > >I believe I have finshed converting the built-in renderers to my > > > >pluggable rendering system. > > > ... > > > >Do they, or > > > >anyone else working with the rendering system, expect my modifications > > > >to cause conflicts with there improvements? > > > > > > I would need to examine the code to determine that. What was your > > > specific goal for this modification? For instance, SkyJUMP has > > > additional hard-coded (special selection feedback) renderers to > > > support a new Audit Geometry tool. Would your pluggable mod remove > > > the necessity for these to pollute the name space in the > > > RenderingManager? > > > > > > regards, > > > Larry Becker > > > > > > On 7/24/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > > > > > > > > > > [1] I noticed that OpenJUMP passes a "SCALE_SHOW" String to each tasks > > > > > RenderingManager. I wasn't able to find a Renderer for this String. I > > > > > did find an InstallScaleShowPlugIn class. This class has an > > > > > org.openjump package structure, so I don't think it was included in > > > > > the original JUMP. Does anyone know what the purpose of this plug-in > > > > > is and how it relates to the rendering of the scale bar in OpenJUMP. I > > > > > need to figure how to integrate it into my pluggable rendering system. > > > > > > > > mhm.. as far as i remember i did not change something in the core. > > > > The code i used to display the "scale" as number (i assume you talk > > > > about this) was more or less a copy of the "scale bar" code from Jump. > > > > > > > > so i am not sure where this change should come from (would be good to > > > > look in the history of the file that provides the string). > > > > > > > > It may actually be, that this string is used for the project settings > > > > and has been added by Jon/Martin for the scale bar. > > > > > > > > stefan > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > This SF.net email is sponsored by: Splunk Inc. > > > > Still grepping through log files to find problems? Stop. > > > > Now Search log events and configuration files using AJAX and a browser. > > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > > _______________________________________________ > > > > Jump-pilot-devel mailing list > > > > Jump-pilot-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > > > > > > > > -- > > > http://amusingprogrammer.blogspot.com/ > > > > > > ------------------------------------------------------------------------- > > > This SF.net email is sponsored by: Splunk Inc. > > > Still grepping through log files to find problems? Stop. > > > Now Search log events and configuration files using AJAX and a browser. > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > _______________________________________________ > > > 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: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > -- > http://amusingprogrammer.blogspot.com/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
