Re: [mylyn-integrators] AbstractTask vs. RepositoryTaskData in aconnecto

[Steffen Pingel <steffenp@xxxxxx>]

> > RepositoryTaskData [TaskData] is a hierarchical connector managed data
> > structure. It is stored in XML files in the .offline [.tasks] folder.
> > Task data is a map of attributes that are identified by unique keys.
> > Each attribute has values (list of Strings), options (key-value map
> > of Strings) and meta-data (key-value map of Strings). In addition
> > task attributes can be nested in Mylyn 3.0.
[...]
> The only "metadata" that I can think of is constant for a given
> attribute (data type, max. length, range of possible values, required
> format, etc.).  Is that the kind of information that you're expecting to
> be used for meta-data?

Yes, that is right. In Mylyn 3.0 the set of meta-data attributes used by the 
framework is defined in TaskAttributeProperties: readOnly, kind, type...

> > > Are those
> > > instances supposed to carry all of these fields, too?  Or are they
> > > supposed to carry only enough information for the UI?
> >
> > Instances of AbstractTask [ITask] should have just enough information
> > to represent them in the tasks view. It is probably sufficient to
> > simply extend AbstractTask and override the few abstract methods
> > without storing additional state. This will also make porting to
> > Mylyn 3.0 easier.
>
> OK.  So, if I need to return some representation of all of the data from
> a SOAP client, for example, I shouldn't try to stuff it all into my
> AbstractTask subclass?  That is, I might have separate classes for my
> task for the following cases:
>
> ClientTask - a representation of the task used by my web service client
> that is tied to a specific web service
>
> TransferTask - a representation of all of the task attributes that I can
> use to move that data between a web service client class and other task
> classes (TransferTask would be client neutral in the case that my
> connector has multiple different clients so that ITrackerClient can
> declare a consistent API.)

I would consider to rely on ClientTask unless there is strong indication that 
there is going to be more than one client implementation.

> MyAbstractTaskSubclass - a representation of just the task attributes
> needed for the Task List UI

(In Mylyn 3.0 this class won't be necessary anymore.)

> RepositoryTaskData - a representation of all of the task information as
> a mapping of attributes, used for offline editing and persistence
>
>
> I was trying to get rid of TransferTask, but that actually looks
> difficult to do.  The web service client needs to return *something*,
> but ClientTask may be too tied to the web service itself, the
> AbstractTask subclass won't necessarily carry all of the data, and I
> don't see anyone returning RepositoryTaskData instances directly from
> their web service client code.  Perhaps the cleanest thing is to create
> that TransferTask class.

In Mylyn 2.x connectors have a choice of either providing AbstractTask objects 
or RepositoryTaskData objects as query results. In Mylyn 3.0 this has been 
simplified and connectors will always need to provide task data objects 
(SaxBugzillaQueryContentHandler in cvs head is an example). The tasks 
framework then creates/updates the tasks in the task list from those task 
data objects. This bug discusses the changes in the framework in more detail:

220034: [api] determine split between RepositoryTaskData and AbstractTask
https://bugs.eclipse.org/bugs/show_bug.cgi?id=220034

Steffen

-- 
Steffen Pingel - steffenp@xxxxxx - http://steffenpingel.de