Larry, Thanks for looking at the code in question.
You wrote: "I followed the code in InstallRendererPlugIn, but never found an actual listener that invokes it." I may not understand how the code is working. I thought that the initialize method of the InstallRendererClass registered a ConainterAdapter with the WorkbenchFrame. It appeared to me that this would then add a renderer to each new TaskFrame if necessary. (Note: The ContainerAdapter isn't in a separate class, I think it is in what is called an inner class. In other words, it is defined within the initialize method of the InstallRendererPlugIn class.) If I do understand this code correctly then OpenJUMP checks each component added to the WorkbenchFrame to see if it is a TaskFrame. If it is a TaskFrame any needed renderers are added. Larry wrote: "I would agree that the Task is part of the model, but the TaskFrame is part of the view." This is clearer to me now, thanks. Larry wrote: "The usual reason for separating the two is that you can change the UI without touching the Domain Logic and vice versa, however the renderer has a foot in both worlds." Good point. Larry wrote: "You may have a legitimate need to create a TaskFactory class, but IMO it can't really be justified as cleaning up the architecture." I agree. Now that you have helped me understand that a renderer is really part of the view, I can see that the current design of OpenJUMP is not in error. I was simply thinking it would have been more elegant to have a "non-gui" event mechanism represent task creation, instead of depending on the adding of a child component to a JFrame. This would allow plug-in code, or even code in the core, to respond to actual task creation, not addition of a task frame, which to me could be two (2) different events. This design might even be more efficient, since the code to check for task frames wouldn't be executed everytime an internal frame was added to the workbench. There is also the risk, although it is very small, that changes to Swing could mess with the current mechanism. I just thought there would be some benefits to modeling task creation separate from the GUI. Thanks for your thoughts. You have helped me to understand this better. The Sunburned Surveyor On Jan 8, 2008 8:00 AM, Larry Becker <[EMAIL PROTECTED]> wrote: > Hi Sunburned, > > I followed the code in InstallRendererPlugIn, but never found an > actual listener that invokes it. I'm not sure that I see the problem > though. I would agree that the Task is part of the model, but the > TaskFrame is part of the view (in the Model View Controller paradigm). > The renderer would seem to be the interface between the model and the > view. The usual reason for separating the two is that you can change > the UI without touching the Domain Logic and vice versa, however the > renderer has a foot in both worlds. > > You may have a legitimate need to create a TaskFactory class, but > IMO it can't really be justified as cleaning up the architecture. > > regards, > Larry > > > On Jan 8, 2008 9:22 AM, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > > Larry, > > > > I ran across this code when I was designing my pluggable rendering > > system. I realized that JUMP adds renderers to each task frame by > > "listening" for task frame creation. It accomplishes this by > > registering a ContainerListener with the WorkbenchFrame. Everytime a > > component is added to the WorkbenchFrame Openjump checks to see if it > > is a TaskFrame. If it is a TaskFrame the renderers are added. > > > > You can find the code in the InstallRendererPlugIn class. Look at the > > initialize method. > > > > I hope that helps. > > > > The Sunburned Surveyor > > > > > > On Jan 8, 2008 6:08 AM, Larry Becker <[EMAIL PROTECTED]> wrote: > > > Hi Sunburned, > > > > > > What code are you referring to specifically? > > > > > > Larry > > > > > > > > > On Jan 7, 2008 2:31 PM, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > > > > There is some code in OpenJUMP that "listens" for child components to > > > > be added to the Workbench in order to detect when a Task has been > > > > added. I think this is likely a violation of the "separation of GUI > > > > and model" principle. (Unless we view a task solely as a GUI > > > > component.) > > > > > > > > I wonder if there would be objections to adding an event to signify > > > > task creation that did not depend on listening for Swing operations in > > > > this way. The event could be fired by a new class called TaskFacotry > > > > or something similar. The TaskFactory class would call the createTask > > > > method of the WorkbenchFrame and then fire the event. This would allow > > > > us to do some neat things in the future, such as potentially add a > > > > task but delay displaying it on the workbench. It would also allow us > > > > to immediately decouple "listeners" for task creation from the GUI. > > > > > > > > At some point I'd like to add a plug-in for task management, which > > > > would use this listening mechanism. I also already have code in the > > > > pluggable rendering system I designed that could be decoupled in this > > > > way. > > > > > > > > At any rate, I wonder if there would be strong opposition to adopting > > > > this type of change in the core, if I worked it up. If there are good > > > > reasons not to do this, I won't even consider it. > > > > > > > > The Sunburned Surveyor > > > > > > > > ------------------------------------------------------------------------- > > > > Check out the new SourceForge.net Marketplace. > > > > It's the best place to buy or sell services for > > > > just about anything Open Source. > > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > > > _______________________________________________ > > > > Jump-pilot-devel mailing list > > > > Jump-pilot-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > > > > > > > > > > > -- > > > http://amusingprogrammer.blogspot.com/ > > > > > > ------------------------------------------------------------------------- > > > Check out the new SourceForge.net Marketplace. > > > It's the best place to buy or sell services for > > > just about anything Open Source. > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > > _______________________________________________ > > > Jump-pilot-devel mailing list > > > Jump-pilot-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > > ------------------------------------------------------------------------- > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services for > > just about anything Open Source. > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > _______________________________________________ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > -- > http://amusingprogrammer.blogspot.com/ > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
