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
