Sounds good Paul.
The Sunburned Surveyor
On Tue, May 27, 2008 at 10:23 AM, Paul Austin <[EMAIL PROTECTED]> wrote:
> All,
>
> I have checked in the change so you can add properties to a Task.
> Properties are keyed by a QName instance, see
> org.openjump.core.model.OpenJumpTaskProperties for the l
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 direc
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 propert
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/wor
Michael,
The magic is new in JDK 1.5 generics. It's a generic method the
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 t
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
