Hei, to me it sounds still a bit abstract (i.e. not sure what you implementation would all encompass in terms of classes and so on) but as martin agrees I have no problems with that.
btw. I would actually prefer to integrate it in the core directly - as it is a needed feature. however, not sure if other things than distances (and areas) are of interest. stefan Martin Davis schrieb: > SS, > > This is exactly the kind of use case the Registry was meant to support. > It is a system-wide repository for non-deleteable value objects of > specific categories. Your scenario for development sounds just fine to me. > > Martin > > Sunburned Surveyor wrote: >> I remembered someone (I think Jon Aquino) mentioning that an object >> called a Registry could be used to access data throughout OpenJUMP. I >> was skimming the Javadoc for the Registry class and I think I can use >> it to allow plug-ins to contribute unit systems. >> >> In this scenario the unit system contribution would work something like this: >> >> [1] The plug-in programmer would implement an extension of the >> standard plug-in interface built specifically to contribute unit >> systems. >> >> [2] In the plug-in's initialize() method the programmer would create >> and store an object containing some basic information about the unit >> system his plug-in would contribute. This would include a user >> friendly name for the unit system, the type of unit system, and the >> fully qualified name of the class that implements the UnitSystem >> interface. This object would be added to the registry using the >> classification, or key, "Unit Systems Information". (Each >> implementation of the UnitSystem interface would require a no-argument >> constructor.) >> >> [3] Other OpenJUMP plug-in programmers could ask the registry for all >> unit system information objects. These could be used to build a list >> of unit systems available to the user. When a unit system was needed, >> a instance could be created using the fully qualified class name in >> the unit system information object and the classForName method. (Thus >> the requirement for a no argument constructor.) >> >> Any thoughts on this approach? Its not the most elegant, but I think >> it will work within the constraints of our existing plug-in system >> without requiring any modifications to the core. >> >> The Sunburned Surveyor >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >> Don't miss this year's exciting event. There's still time to save $100. >> Use priority code J8TL2D2. >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone >> _______________________________________________ >> 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 the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
