Paul, You are probably correct in stating that an extension of the AbstractPlugIn class may not be the most elegant solution for supporting user-specific behavior in OpenJUMP. Perhaps I can explain a little of the "bigger picture" that I am trying to accomplish. This may help you understand why I had originally thought of using an abstract plug-in extension.
I'm a proponent of keeping OpenJUMP's core very light, and of encouraging developers to use plug-in to add functionality to OpenJUMP. As a result, I plan on adding as much of my own new functionality to OpenJUMP as I can via plug-ins. I want to add some "infrastructure" to OpenJUMP that will make plug-in development and management easier, and will improve cooperation among plug-ins during runtime. I didn't want to impose these changes to the plug-in infrastructure on other developers for a number of reasons. (For one thing, this is still experiemental. I don't know how it will work yet.) The beauty of this situation is that I can use the existing plug-in framework to create my plug-in infrastructure with very few modifications to the core. Here is my basic concept: I will design a plug-in for OpenJUMP called SurveyOSMain. I will also design a subclass of the AbstractPlugIn class named a SurveyOSPlugIn. The SurveyOSMain plug-in will provide services to any implementations of the SurveyOSPlugIn class. Most of these implementations will be written by myself, but they could be written by any plug-in developer that also wanted to take advantage of the services offered by the SurveyOSMain class. So what are some of the services I want to offer through the SurveyOSMain class? - Installation, removal, and updating of SurveyOS plug-ins through the OpenJUMP GUI. (Developers of a SurveyOS Plug-In for OpenJUMP will be required to create distributions of their plug-in that follow a set folder structure. The SurveyOSMain plug-in will then copy OpenJUMP libraries, SurveyOS libraries, plug-in specific libraries, and extension JAR files to the appropriate locations during the installation process. Execution of pre-installation scripts and post installation scripts will also be supported.) I hope to eventually support updates of SurveyOS OpenJUMP plug-ins over the web, as can be done in Eclipse. - User management of plug-ins through the OpenJUMP GUI. Users will be able to view which SurveyOS Plug-ins are currently installed. They will also be able to view information about the date of the installation, a description of the plug-ins functionality, plug-in dependencies, and the current execution status of the plug-in. - Support for Plug-In dependency. Each SurveyOs Plug-In will know what other SurveyOS Plug-Ins have been installed, and which plug-ins have been successfully or unsucessfully intialized. They will be able to access the public API of other SurveyOS plug-ins during runtime. - Support for configuration of SurveyOS Plug-In behavior. This could be "global" behavior of all SurveyOS Plug-Ins that share common functinoality (for example: snapping during feature editing operations). It could be plug-in specific, or it might be user specific. The SurveyOSPlugIn class will include the API needed to store and retrieve these configuration settings so that it doesn't have to be implemented by each plug-in developer. - Storage of project, task, organization, and user information that can be accessed by SurveyOS plug-ins dealing with metadata creation/editing or logging and reporting. - Support for implementation of Observer design patterns between SurveyOS plug-ins. For example, each SurveyOS plug-in will broadcast events that indicate when execution of the plug-in has begun, and when it has completed. In summary, I am hoping to create plug-in infrastructure for a tightly-knit group of plug-ins. I hope to do this using a "mothership" plug-in that follows the rules of the current plug-in system. I don't think my system will be for everyone. OpenJUMp's current plug-in system is fairly light-weight with few restrictions on the plug-in developer. My plug-in system is heavier, with more restrictions for the plug-in developer. The cost-benefit ratio won't make sense for a lot of plug-in programmers, because the services offered by SurveyOSMain won't be needed by a lot of plug-ins. I welcome any comments you or the other programmers may have. If it makes sense to have a "user-specific" configuration mechanism in the core, I won't include it in SurveyOSMain. The Sunburned Surveyor On 11/2/07, Paul Austin <[EMAIL PROTECTED]> wrote: > Hi Landon, > > I don't think you need to subclass the Abstract plugin in to do this. > > Looking at the problem there are a couple of things to think about. I'm > going to use the concept of a workspace (think eclipse) for each of a user's > different configurations of JUMP > > > There will need to be some global settings for a user that's aren't specific > to a workspace (such as the list of recent workspaces or a default > workspace. Maybe the log4j configuration. > There are settings that would be specific to workspaces, such as the > settings saved from the PersistentBlackboard plug-in (workbench-state.xml) > and the workbench configuration (workbench-properties.xml). > So what is a workspace, a workspace is a directory with a bunch of files in > it. Think of this as the configuration directory. When the JUMP starts up it > can look at the settings in #1 for the user <user's home dir>/.openjump/ > directory. Then if they don't have a default workspace set they will be > given the option to open or create a workspace. This would then set a > property in the blackboard called OPEN_JUMP_WORKSPACE with a java.io.File to > the workspace directory. > > Then if plug-ins want to get some configuration file or create one in the > workspace they would use the OPEN_JUMP_WORKSPACE as the root directory for > those files. > > This way plug-ins don't need to know about workspaces per-se just that there > is a directory to put the configuration files into. > > Paul > > > Sunburned Surveyor wrote: > Thanks Uwe. I'm going to proceed with my "current user" functionality. This > will be included in a class that extends the JUMP AbstractPlugIn class, so > the functionality will be available to other plug-in developers if they so > choose. I'll be trying to modify the Super Select tool so that > the configurations can be stored separately for different users using > this scenario. Look for it in an upcoming release of the plug-in. The > Sunburned Surveyor On 11/2/07, Uwe Dalluege <[EMAIL PROTECTED]> > wrote: > Hi Landon, if you are teaching OpenJUMP you have one installation and lots > of students using OpenJUMP over a network. It would be very nice to have a > plugIn to configure the personal settings. Regards Uwe Sunburned Surveyor > schrieb: > I'd like to know if anyone is using OpenJUMP in a situation where more than > one person would using an OpenJUMP installation on a single computer. This > might happen if OpenJUMP were being accessed over a network, or if more than > one person accessed a computer with OpenJUMP installed to perform GIS > tasks. I'd like to know how common this scenario is because I am trying > to determine how useful it would be to design plug-ins for OpenJUMP > that maintain "current user information". This functionality would allow you > to store personalized tool configurations for each user and would also be > used to identify the user/organizatoin for logging and metadata tools. (I > don't intend to use the "current user information" functionality to control > or restrict access to data or functions in OpenJUMP. That is a whole other > can of worms and not my goal in this case.) Thanks, The Sunburned > Surveyor ------------------------------------------------------------------------- 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 > ------------------------------------------------------------------------- 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 > > ------------------------------------------------------------------------- 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
