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
