Paul wrote: "If you have two copies of the application running you can get a corrupted file if one is trying to load the file while another is writing to it. Maybe we need a locking mechanism."
You mean like a lock file? That would really be the only thing that would work across multiple instances of OpenJUMP, correct? You wrote: "All users share the same properties file unless you change it in the batch script to point to a user specific directory." I thought about making an extension of AbstractPlugIn that allowed access to user-specific properties. If this is a need common to multiple developers, perhaps we should consider a global solution that could be used by everyone? The Sunburned Surveyor On Tue, May 27, 2008 at 10:57 AM, Paul Austin <[EMAIL PROTECTED]> wrote: > Sounds like people don't like the preferences API so I won't use it for > anything in the core JUMP. I'll just use it in my plug-ins where I need > immediate saving of preferences. > > There are a couple of problems with the current persistent blackboard. > > If you have two copies of the application running you can get a corrupted > file if one is trying to load the file while another is writing to it. Maybe > we need a locking mechanism > All users share the same properties file unless you change it in the batch > script to point to a user specific directory > > Paul > > > Martin Davis wrote: > > I would NOT be in favour of any persistence feature which uses the > Windows Registry. It's way too hard to work with. What's wrong with > text-based (incl. XML) config files located in the application directory > itself? > The other problem with the Registry is that it effectively limits you to > a single version of the JUMP application. It's very useful to have a > design which keeps all JUMP config files in the directory for the > instance that created them. Then you can easily have multiple > instances, multiple versions, and copy them from machine to machine. > And then of course there's the issue with backwards compatibility, both > with installed base, existing code, and existing design. > Paul Austin wrote: > > > The (persistent) blackboard at the moment is for the whole workbench > and not specific to a project. There are blackboards for other things > such as a layer but not for a task. For tasks I don't see the benefit > of having a blackboard on a task to store the properties, they might > was well go directly on the task. In terms of saving the properties on > a task it uses the XML2Java class to serialize it, so all you would > need to do is make sure each property could be serialized and read by > that class. I would have it so that if an object could not be > serialized it would be ignored with a warning written. We could also > add guidelines that say what kinds of values are supported for > properties such as all primitive types, Strings and QNames. Most > properties would be these anyway. > For the previous projection request I had, the plan would be that this > would be a property added to the task using this new mechanism. > I was also thinking of having a Class with constants listing all of > the "standard" properties supported in OpenJump. This class would be > called something like OpenJumpTaskProperties. > For things that the persistent blackboard is used for I'd actually > prefer to switch over to using the Java Preferences API. The advantage > of this is you can support user v.s. computer based saved > configuration. The configuration is saved immediately rather than when > you exit the application. And the config is saved in a location (e.g. > windows registry) that is specific to the platform. > Paul > *Paul Austin* > /President/CEO/ > Revolution Systems Inc. > +1 (604) 288-4304 x201 > www.revolsys.com <http://www.revolsys.com> > Stefan Steiniger wrote: > > > in general I support Pauls idea, although I am wondering what has been > happened to the first request on adding a Projection property to the Taks. > But Paul, can you also say why it is better to have properties than > using the blackboard? I could imagine, that one simply knows what type > of properties exist - while on the blackboard could be anything. But how > do I know which properties are existent? > @Larry and Andreas: Any comments from you on that? > (I ask you too as you have way more programming experience than I > have... i.e. I am rather part of the "weeks" group outlined in the memo > thread ;o) > cheers > stefan > Sunburned Surveyor schrieb: > > > > Paul wrote: "I would like to extend the Task class to support > properties. Properties > can be set by plug-ins on the task." > I wonder if we could use a Blackboard and PersistentBlackboardPlugIn > to accomplish this? > http://jump-pilot.sourceforge.net/javadoc/openjump_javadoc/com/vividsolutions/jump/workbench/ui/plugin/PersistentBlackboardPlugIn.html > http://jump-pilot.sourceforge.net/javadoc/openjump_javadoc/com/vividsolutions/jump/util/Blackboard.html > This would keep things a little simpler, as we'd be using classes that > are already present in OpenJUMP. > This is just a suggestion. > If we support Objects, how will we represent their state when we write > the data to the Task file? Will we just call toString on the object, > or will there be another method? > The Sunburned Surveyor > On Sat, May 24, 2008 at 8:55 AM, Paul Austin <[EMAIL PROTECTED]> > wrote: > > > > Michael, > The magic is new in JDK 1.5 generics. It's a generic method the <T> means > that at compile time it should deduce anywhere it sees T (T can be anything > you want) in the method based on the actual classes used. > So in the below example we use T as the return type so the compiler can pick > this up from your assignment statement Integer i = task.getProperty(...) and > then use Integer where ever it sees T. > public <T> T getProperty(QName name) { > return (T)properties.get(name); > } > This just makes your code a lot easier to read as you don't have to cast in > your code > http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf section 5 generic > methods > Paul > Michael Michaud wrote: > Paul Austin a écrit : > I would like to extend the Task class to support properties. Properties > can be set by plug-ins on the task. An example of a property would be > the SRID for the whole task. This will allow us to support extended > metadata on tasks without having to add new methods each time or > subclassing. > Seems to be a good idea to me. > I propose to use QName's as the key for the keys for the properties. > This would allow different namespaces for different applications. > The change would include the following. > private void Map<QName,Object> properties = new HashMap<QName,Object>(); > public void setProperty(QName name, Object value) { > properties.put(name, value); > } > /** > * This will auto cast so you can just type things like > * int value = getProperty(MY_KEY); > */ > public <T> T getProperty(QName name) { > return (T)properties.get(name); > } > Hey, looks like magic code. > I cannot understand how the type T can be used in an object method if it > has not been declared in the class definition. > Can really the jvm know how to cast properties.get(KEY) while the object > associated with this key can be any Object value? > Michaël > public Map<QName,Object> getProperties() { > } > We'd also need to have it setup so this would be saved to the project file. > Any suggestions/comments? > Paul > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > 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: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > 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: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > 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: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > 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: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > 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: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > ------------------------------------------------------------------------ > _______________________________________________ > 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: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
