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
