Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Mylyn » Representation of tasks in trac connector
Representation of tasks in trac connector [message #34654] Thu, 01 November 2007 00:57 Go to next message
Eclipse UserFriend
Originally posted by: googelybear.gmail.com

Hi everyone,

I'm implementing a connector for the origo project (origo.ethz.ch). So I
had a look at the trac connector which is mentioned several times on the
integrator wiki, but I'm confused with the represenation of tasks. To
me it appears that there are 3 different representations: First there is
TracTicket, then TaskData and at last TracTask - Can someone please
explain the rationale behind this? E.g. why is not always TracTask used
- is it only for UI purposes?

Another question related to this: What is the AttributeFactory good for?

Thanks for any help!

Dennis
Re: Representation of tasks in trac connector [message #34722 is a reply to message #34654] Thu, 01 November 2007 19:16 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: steffen.pingel.eclipse.org

Hi,

you are right that there are three different ways a Trac task is
represented:

- TracTicket: this is the representations retrieved from the Trac
repository. It is either created from the data received through XML-RPC or
from the web interface. This is part of a generic API for accessing Trac
repositories that does not depend on Mylyn (except for
org.eclipse.mylyn.web.core).

- TracTask: represents the task information in the task list. This is kept
in memory at all times and contains information needed by Mylyn to
represent the task in the UI. TracTasks are updated from TracTickets or
from RepositoryTaskData (see TracRepositoryConnector.updateFrom*()).

- RepositoryTaskData: used for offline editing and offline storage. Task
data stores all information about a task in RepositoryTaskAttribute
objects. These are used by the editor to create widgets for editing,
determine incoming changes etc. RepositoryTaskData is created in
TracTaskDataHandler from TracTickets.

AttributeFactory is used to map Mylyn's data model to a repository connector
specific model. For example Mylyn uses the
RepositoryTaskAttribute.USER_REPORTER key as the id for the attribute that
specifies the reporter of a task which is mapped to the Trac specific key
TracTicket.Key.REPORTER by TracAttributeFactory.

If you do not need rich editor support you can start out by extending
AbstractTask first and open a web browser for editing tasks. In a second
step you can implement an attribute factory, a task data handler and an
editor factory which will add rich offline editing.

Hope this helps.

Steffen


> Hi everyone,
>
> I'm implementing a connector for the origo project (origo.ethz.ch). So I
> had a look at the trac connector which is mentioned several times on the
> integrator wiki, but I'm confused with the represenation of tasks. To
> me it appears that there are 3 different representations: First there is
> TracTicket, then TaskData and at last TracTask - Can someone please
> explain the rationale behind this? E.g. why is not always TracTask used
> - is it only for UI purposes?
>
> Another question related to this: What is the AttributeFactory good for?
>
> Thanks for any help!
>
> Dennis
Re: Representation of tasks in trac connector [message #34788 is a reply to message #34722] Thu, 01 November 2007 20:09 Go to previous messageGo to next message
Eugene Kuleshov is currently offline Eugene KuleshovFriend
Messages: 504
Registered: July 2009
Senior Member
I am starting to wonder if connector should be using
RepositoryTaskData for internal stuff instead of maintaining 3rd structure.

regards,
Eugene


Steffen Pingel wrote:
> Hi,
>
> you are right that there are three different ways a Trac task is
> represented:
>
> - TracTicket: this is the representations retrieved from the Trac
> repository. It is either created from the data received through XML-RPC or
> from the web interface. This is part of a generic API for accessing Trac
> repositories that does not depend on Mylyn (except for
> org.eclipse.mylyn.web.core).
>
> - TracTask: represents the task information in the task list. This is kept
> in memory at all times and contains information needed by Mylyn to
> represent the task in the UI. TracTasks are updated from TracTickets or
> from RepositoryTaskData (see TracRepositoryConnector.updateFrom*()).
>
> - RepositoryTaskData: used for offline editing and offline storage. Task
> data stores all information about a task in RepositoryTaskAttribute
> objects. These are used by the editor to create widgets for editing,
> determine incoming changes etc. RepositoryTaskData is created in
> TracTaskDataHandler from TracTickets.
>
> AttributeFactory is used to map Mylyn's data model to a repository connector
> specific model. For example Mylyn uses the
> RepositoryTaskAttribute.USER_REPORTER key as the id for the attribute that
> specifies the reporter of a task which is mapped to the Trac specific key
> TracTicket.Key.REPORTER by TracAttributeFactory.
>
> If you do not need rich editor support you can start out by extending
> AbstractTask first and open a web browser for editing tasks. In a second
> step you can implement an attribute factory, a task data handler and an
> editor factory which will add rich offline editing.
>
> Hope this helps.
>
> Steffen
>
>
>
>> Hi everyone,
>>
>> I'm implementing a connector for the origo project (origo.ethz.ch). So I
>> had a look at the trac connector which is mentioned several times on the
>> integrator wiki, but I'm confused with the represenation of tasks. To
>> me it appears that there are 3 different representations: First there is
>> TracTicket, then TaskData and at last TracTask - Can someone please
>> explain the rationale behind this? E.g. why is not always TracTask used
>> - is it only for UI purposes?
>>
>> Another question related to this: What is the AttributeFactory good for?
>>
>> Thanks for any help!
>>
>> Dennis
>>
>
>
Re: Representation of tasks in trac connector [message #34822 is a reply to message #34788] Thu, 01 November 2007 20:15 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: steffen.pingel.eclipse.org

This will largely depend on the remote interface of the repository. For
repositories that use SOAP the data classes can be generated. In the case
of Trac the advantage of having an implementation that is independent of
the Mylyn tasks framework makes it potentially reusable for other projects
as well. Also the additional data classes allow to abstract from underlying
access method. The web mode does not support offline/rich editing so it
does not make much sense to use task data there. AFAIK the Bugzilla
connector does not have a separate data structure but uses task data
directly.

Steffen


Eugene Kuleshov wrote:

>
> I am starting to wonder if connector should be using
> RepositoryTaskData for internal stuff instead of maintaining 3rd
> structure.
>
> regards,
> Eugene
>
>
> Steffen Pingel wrote:
>> Hi,
>>
>> you are right that there are three different ways a Trac task is
>> represented:
>>
>> - TracTicket: this is the representations retrieved from the Trac
>> repository. It is either created from the data received through XML-RPC
>> or from the web interface. This is part of a generic API for accessing
>> Trac repositories that does not depend on Mylyn (except for
>> org.eclipse.mylyn.web.core).
>>
>> - TracTask: represents the task information in the task list. This is
>> kept in memory at all times and contains information needed by Mylyn to
>> represent the task in the UI. TracTasks are updated from TracTickets or
>> from RepositoryTaskData (see TracRepositoryConnector.updateFrom*()).
>>
>> - RepositoryTaskData: used for offline editing and offline storage. Task
>> data stores all information about a task in RepositoryTaskAttribute
>> objects. These are used by the editor to create widgets for editing,
>> determine incoming changes etc. RepositoryTaskData is created in
>> TracTaskDataHandler from TracTickets.
>>
>> AttributeFactory is used to map Mylyn's data model to a repository
>> connector specific model. For example Mylyn uses the
>> RepositoryTaskAttribute.USER_REPORTER key as the id for the attribute
>> that specifies the reporter of a task which is mapped to the Trac
>> specific key TracTicket.Key.REPORTER by TracAttributeFactory.
>>
>> If you do not need rich editor support you can start out by extending
>> AbstractTask first and open a web browser for editing tasks. In a second
>> step you can implement an attribute factory, a task data handler and an
>> editor factory which will add rich offline editing.
>>
>> Hope this helps.
>>
>> Steffen
>>
>>
>>
>>> Hi everyone,
>>>
>>> I'm implementing a connector for the origo project (origo.ethz.ch). So I
>>> had a look at the trac connector which is mentioned several times on the
>>> integrator wiki, but I'm confused with the represenation of tasks. To
>>> me it appears that there are 3 different representations: First there is
>>> TracTicket, then TaskData and at last TracTask - Can someone please
>>> explain the rationale behind this? E.g. why is not always TracTask used
>>> - is it only for UI purposes?
>>>
>>> Another question related to this: What is the AttributeFactory good for?
>>>
>>> Thanks for any help!
>>>
>>> Dennis
>>>
>>
>>
Re: Representation of tasks in trac connector [message #35526 is a reply to message #34822] Mon, 05 November 2007 10:17 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: googelybear.gmail.com

First of all, thanks a lot for your explanations and taking the time to
write it all down, it gave me quite some insight.

In the long run I need rich editing support, but it would be very
helpful if I could create a first implementation which uses the existing
web ui for editing and displays tasks in the task list, but I'm not sure
how exactly I can achieve this. For example the
AbstractRepositoryConnector.createTaskFromExistingId method already
requires a TaskDataHandler and TaskData - or can I simply override this
and remove the indirection via TaskData?

I already created a subclass of the AbstractTask which adds the
connector specific fields. The UI plugin implements the ext point
org.eclipse.mylyn.tasks.ui.repositories (which means I created the 3
classes RepositoryConnector, connector ui and the tasklist factory). The
core plugin doesn't use any ext points.

What would be the next steps to create this first implementation?

Two more questions:

1. Am I right, that the TracTaskDataHandler and the attribute factory
are wokring in tandem to populate TaskData objects?

2. In the AbstractTask there is a field "taskId" - should this only be
used internally by mylyn or can I use it to store the external id of an
issue (the one which is also perceptible from the web ui, like the bug
id from bugzilla)?

Thanks again!

Dennis

Steffen Pingel wrote:
> This will largely depend on the remote interface of the repository. For
> repositories that use SOAP the data classes can be generated. In the case
> of Trac the advantage of having an implementation that is independent of
> the Mylyn tasks framework makes it potentially reusable for other projects
> as well. Also the additional data classes allow to abstract from underlying
> access method. The web mode does not support offline/rich editing so it
> does not make much sense to use task data there. AFAIK the Bugzilla
> connector does not have a separate data structure but uses task data
> directly.
>
> Steffen
>
>
> Eugene Kuleshov wrote:
>
>> I am starting to wonder if connector should be using
>> RepositoryTaskData for internal stuff instead of maintaining 3rd
>> structure.
>>
>> regards,
>> Eugene
>>
>>
>> Steffen Pingel wrote:
>>> Hi,
>>>
>>> you are right that there are three different ways a Trac task is
>>> represented:
>>>
>>> - TracTicket: this is the representations retrieved from the Trac
>>> repository. It is either created from the data received through XML-RPC
>>> or from the web interface. This is part of a generic API for accessing
>>> Trac repositories that does not depend on Mylyn (except for
>>> org.eclipse.mylyn.web.core).
>>>
>>> - TracTask: represents the task information in the task list. This is
>>> kept in memory at all times and contains information needed by Mylyn to
>>> represent the task in the UI. TracTasks are updated from TracTickets or
>>> from RepositoryTaskData (see TracRepositoryConnector.updateFrom*()).
>>>
>>> - RepositoryTaskData: used for offline editing and offline storage. Task
>>> data stores all information about a task in RepositoryTaskAttribute
>>> objects. These are used by the editor to create widgets for editing,
>>> determine incoming changes etc. RepositoryTaskData is created in
>>> TracTaskDataHandler from TracTickets.
>>>
>>> AttributeFactory is used to map Mylyn's data model to a repository
>>> connector specific model. For example Mylyn uses the
>>> RepositoryTaskAttribute.USER_REPORTER key as the id for the attribute
>>> that specifies the reporter of a task which is mapped to the Trac
>>> specific key TracTicket.Key.REPORTER by TracAttributeFactory.
>>>
>>> If you do not need rich editor support you can start out by extending
>>> AbstractTask first and open a web browser for editing tasks. In a second
>>> step you can implement an attribute factory, a task data handler and an
>>> editor factory which will add rich offline editing.
>>>
>>> Hope this helps.
>>>
>>> Steffen
>>>
>>>
>>>
>>>> Hi everyone,
>>>>
>>>> I'm implementing a connector for the origo project (origo.ethz.ch). So I
>>>> had a look at the trac connector which is mentioned several times on the
>>>> integrator wiki, but I'm confused with the represenation of tasks. To
>>>> me it appears that there are 3 different representations: First there is
>>>> TracTicket, then TaskData and at last TracTask - Can someone please
>>>> explain the rationale behind this? E.g. why is not always TracTask used
>>>> - is it only for UI purposes?
>>>>
>>>> Another question related to this: What is the AttributeFactory good for?
>>>>
>>>> Thanks for any help!
>>>>
>>>> Dennis
>>>>
>>>
>
Re: Representation of tasks in trac connector [message #35712 is a reply to message #35526] Mon, 05 November 2007 21:53 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: steffen.pingel.eclipse.org

> In the long run I need rich editing support, but it would be very
> helpful if I could create a first implementation which uses the existing
> web ui for editing and displays tasks in the task list, but I'm not sure
> how exactly I can achieve this. For example the
> AbstractRepositoryConnector.createTaskFromExistingId method already
> requires a TaskDataHandler and TaskData - or can I simply override this
> and remove the indirection via TaskData?

Yes, you should override this method and provide an implementation that
returns a task object of your connector specific class. The properties on
the task object should be updated from the repository in that method.

> I already created a subclass of the AbstractTask which adds the
> connector specific fields. The UI plugin implements the ext point
> org.eclipse.mylyn.tasks.ui.repositories (which means I created the 3
> classes RepositoryConnector, connector ui and the tasklist factory). The
> core plugin doesn't use any ext points.
>
> What would be the next steps to create this first implementation?

That sounds great. The next step is to implement querying support. That
involves implementing a wizard that is returned by
AbstractRepositoryConnectorUi.getQueryWizard() and implementing the query
logic in AbstractRepositoryConnector.performQuery().

> 1. Am I right, that the TracTaskDataHandler and the attribute factory
> are wokring in tandem to populate TaskData objects?

Yes, that is correct. The attribute factory is mostly used for the attribute
key mapping.

> 2. In the AbstractTask there is a field "taskId" - should this only be
> used internally by mylyn or can I use it to store the external id of an
> issue (the one which is also perceptible from the web ui, like the bug
> id from bugzilla)?

Each task needs to have a key that uniquely identifies that task in the
repository and never changes. You are right that the Bugzilla connector
uses the bug id that is also visible in the web ui. There is a second field
named taskKey that can be used to store a more descriptive identifier that
may change (e.g. JIRA uses that). The taskKey is used when Mylyn displays
the task id in the UI.

Steffen
Re: Representation of tasks in trac connector [message #35882 is a reply to message #35712] Wed, 07 November 2007 13:59 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: googelybear.gmail.com

Ok great, I think I now got everything together to retrieve existing
tasks when the task id is provided. But when I righ-click on the
repository and select "open repository task" and enter an id it says
"could not find mathcing repository task". I already started eclipse in
debug mode and played around with brakpoints, but I couldn't figure out
which method of my connector gets called when I press "ok". Can you give
me a hint here?

thanks again,
Dennis

Steffen Pingel wrote:
>> In the long run I need rich editing support, but it would be very
>> helpful if I could create a first implementation which uses the existing
>> web ui for editing and displays tasks in the task list, but I'm not sure
>> how exactly I can achieve this. For example the
>> AbstractRepositoryConnector.createTaskFromExistingId method already
>> requires a TaskDataHandler and TaskData - or can I simply override this
>> and remove the indirection via TaskData?
>
> Yes, you should override this method and provide an implementation that
> returns a task object of your connector specific class. The properties on
> the task object should be updated from the repository in that method.
>
>> I already created a subclass of the AbstractTask which adds the
>> connector specific fields. The UI plugin implements the ext point
>> org.eclipse.mylyn.tasks.ui.repositories (which means I created the 3
>> classes RepositoryConnector, connector ui and the tasklist factory). The
>> core plugin doesn't use any ext points.
>>
>> What would be the next steps to create this first implementation?
>
> That sounds great. The next step is to implement querying support. That
> involves implementing a wizard that is returned by
> AbstractRepositoryConnectorUi.getQueryWizard() and implementing the query
> logic in AbstractRepositoryConnector.performQuery().
>
>> 1. Am I right, that the TracTaskDataHandler and the attribute factory
>> are wokring in tandem to populate TaskData objects?
>
> Yes, that is correct. The attribute factory is mostly used for the attribute
> key mapping.
>
>> 2. In the AbstractTask there is a field "taskId" - should this only be
>> used internally by mylyn or can I use it to store the external id of an
>> issue (the one which is also perceptible from the web ui, like the bug
>> id from bugzilla)?
>
> Each task needs to have a key that uniquely identifies that task in the
> repository and never changes. You are right that the Bugzilla connector
> uses the bug id that is also visible in the web ui. There is a second field
> named taskKey that can be used to store a more descriptive identifier that
> may change (e.g. JIRA uses that). The taskKey is used when Mylyn displays
> the task id in the UI.
>
> Steffen
Re: Representation of tasks in trac connector [message #35951 is a reply to message #35882] Thu, 08 November 2007 14:08 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: googelybear.gmail.com

After a while I figured it out by myself, the method that gets called is
TaskUiUtils.openRepositoryTask. But now I'm stuck with the opposite
problem: How can I signal that a task, given its id entered in the "open
repo task" dialog box, does not exist?

The error msg "Could not find matching repository task." appears if
TasksUiUtil.openRepositoryTask returns false. Unfortunately I could not
find the "proper" way or place to achieve this (it must be somewhere
before the OpenRepositoryTaskJob is started, but to find out if a
certain task exists I would have to communicate with the repository...).

Thanks for any help,
Dennis


Dennis R. wrote:
> Ok great, I think I now got everything together to retrieve existing
> tasks when the task id is provided. But when I righ-click on the
> repository and select "open repository task" and enter an id it says
> "could not find mathcing repository task". I already started eclipse in
> debug mode and played around with brakpoints, but I couldn't figure out
> which method of my connector gets called when I press "ok". Can you give
> me a hint here?
>
> thanks again,
> Dennis
>
> Steffen Pingel wrote:
>>> In the long run I need rich editing support, but it would be very
>>> helpful if I could create a first implementation which uses the existing
>>> web ui for editing and displays tasks in the task list, but I'm not sure
>>> how exactly I can achieve this. For example the
>>> AbstractRepositoryConnector.createTaskFromExistingId method already
>>> requires a TaskDataHandler and TaskData - or can I simply override this
>>> and remove the indirection via TaskData?
>>
>> Yes, you should override this method and provide an implementation that
>> returns a task object of your connector specific class. The properties on
>> the task object should be updated from the repository in that method.
>>
>>> I already created a subclass of the AbstractTask which adds the
>>> connector specific fields. The UI plugin implements the ext point
>>> org.eclipse.mylyn.tasks.ui.repositories (which means I created the 3
>>> classes RepositoryConnector, connector ui and the tasklist factory). The
>>> core plugin doesn't use any ext points.
>>>
>>> What would be the next steps to create this first implementation?
>>
>> That sounds great. The next step is to implement querying support. That
>> involves implementing a wizard that is returned by
>> AbstractRepositoryConnectorUi.getQueryWizard() and implementing the query
>> logic in AbstractRepositoryConnector.performQuery().
>>
>>> 1. Am I right, that the TracTaskDataHandler and the attribute factory
>>> are wokring in tandem to populate TaskData objects?
>>
>> Yes, that is correct. The attribute factory is mostly used for the
>> attribute
>> key mapping.
>>
>>> 2. In the AbstractTask there is a field "taskId" - should this only be
>>> used internally by mylyn or can I use it to store the external id of an
>>> issue (the one which is also perceptible from the web ui, like the bug
>>> id from bugzilla)?
>>
>> Each task needs to have a key that uniquely identifies that task in the
>> repository and never changes. You are right that the Bugzilla connector
>> uses the bug id that is also visible in the web ui. There is a second
>> field
>> named taskKey that can be used to store a more descriptive identifier
>> that
>> may change (e.g. JIRA uses that). The taskKey is used when Mylyn displays
>> the task id in the UI.
>> Steffen
Re: Representation of tasks in trac connector [message #36322 is a reply to message #35951] Fri, 16 November 2007 18:20 Go to previous messageGo to next message
Steffen Pingel is currently offline Steffen PingelFriend
Messages: 706
Registered: July 2009
Senior Member
> The error msg "Could not find matching repository task." appears if
> TasksUiUtil.openRepositoryTask returns false. Unfortunately I could not
> find the "proper" way or place to achieve this (it must be somewhere
> before the OpenRepositoryTaskJob is started, but to find out if a
> certain task exists I would have to communicate with the repository...).

You need to throw a CoreException from
AbstractRepositoryConnector.createTaskFromExistingId() or
AbstractTaskDataHandler.getTaskData() in case an invalid ticket id is
requested. OpenRepositoryTaskJob will catch that exception and display an
error dialog.

Steffen
Re: Representation of tasks in trac connector [message #36703 is a reply to message #36322] Mon, 19 November 2007 15:48 Go to previous message
Eclipse UserFriend
Originally posted by: googelybear.gmail.com

Hi Steffen,

Thanks for your tip, the error msg is now correctly displayed. I will
post a follow up question in a separate post.

Dennis

Steffen Pingel wrote:
>> The error msg "Could not find matching repository task." appears if
>> TasksUiUtil.openRepositoryTask returns false. Unfortunately I could not
>> find the "proper" way or place to achieve this (it must be somewhere
>> before the OpenRepositoryTaskJob is started, but to find out if a
>> certain task exists I would have to communicate with the repository...).
>
> You need to throw a CoreException from
> AbstractRepositoryConnector.createTaskFromExistingId() or
> AbstractTaskDataHandler.getTaskData() in case an invalid ticket id is
> requested. OpenRepositoryTaskJob will catch that exception and display an
> error dialog.
>
> Steffen
>
Re: Representation of tasks in trac connector [message #584087 is a reply to message #34654] Thu, 01 November 2007 19:16 Go to previous message
Steffen Pingel is currently offline Steffen PingelFriend
Messages: 706
Registered: July 2009
Senior Member
Hi,

you are right that there are three different ways a Trac task is
represented:

- TracTicket: this is the representations retrieved from the Trac
repository. It is either created from the data received through XML-RPC or
from the web interface. This is part of a generic API for accessing Trac
repositories that does not depend on Mylyn (except for
org.eclipse.mylyn.web.core).

- TracTask: represents the task information in the task list. This is kept
in memory at all times and contains information needed by Mylyn to
represent the task in the UI. TracTasks are updated from TracTickets or
from RepositoryTaskData (see TracRepositoryConnector.updateFrom*()).

- RepositoryTaskData: used for offline editing and offline storage. Task
data stores all information about a task in RepositoryTaskAttribute
objects. These are used by the editor to create widgets for editing,
determine incoming changes etc. RepositoryTaskData is created in
TracTaskDataHandler from TracTickets.

AttributeFactory is used to map Mylyn's data model to a repository connector
specific model. For example Mylyn uses the
RepositoryTaskAttribute.USER_REPORTER key as the id for the attribute that
specifies the reporter of a task which is mapped to the Trac specific key
TracTicket.Key.REPORTER by TracAttributeFactory.

If you do not need rich editor support you can start out by extending
AbstractTask first and open a web browser for editing tasks. In a second
step you can implement an attribute factory, a task data handler and an
editor factory which will add rich offline editing.

Hope this helps.

Steffen


> Hi everyone,
>
> I'm implementing a connector for the origo project (origo.ethz.ch). So I
> had a look at the trac connector which is mentioned several times on the
> integrator wiki, but I'm confused with the represenation of tasks. To
> me it appears that there are 3 different representations: First there is
> TracTicket, then TaskData and at last TracTask - Can someone please
> explain the rationale behind this? E.g. why is not always TracTask used
> - is it only for UI purposes?
>
> Another question related to this: What is the AttributeFactory good for?
>
> Thanks for any help!
>
> Dennis
Re: Representation of tasks in trac connector [message #584106 is a reply to message #34722] Thu, 01 November 2007 20:09 Go to previous message
Eugene Kuleshov is currently offline Eugene KuleshovFriend
Messages: 504
Registered: July 2009
Senior Member
I am starting to wonder if connector should be using
RepositoryTaskData for internal stuff instead of maintaining 3rd structure.

regards,
Eugene


Steffen Pingel wrote:
> Hi,
>
> you are right that there are three different ways a Trac task is
> represented:
>
> - TracTicket: this is the representations retrieved from the Trac
> repository. It is either created from the data received through XML-RPC or
> from the web interface. This is part of a generic API for accessing Trac
> repositories that does not depend on Mylyn (except for
> org.eclipse.mylyn.web.core).
>
> - TracTask: represents the task information in the task list. This is kept
> in memory at all times and contains information needed by Mylyn to
> represent the task in the UI. TracTasks are updated from TracTickets or
> from RepositoryTaskData (see TracRepositoryConnector.updateFrom*()).
>
> - RepositoryTaskData: used for offline editing and offline storage. Task
> data stores all information about a task in RepositoryTaskAttribute
> objects. These are used by the editor to create widgets for editing,
> determine incoming changes etc. RepositoryTaskData is created in
> TracTaskDataHandler from TracTickets.
>
> AttributeFactory is used to map Mylyn's data model to a repository connector
> specific model. For example Mylyn uses the
> RepositoryTaskAttribute.USER_REPORTER key as the id for the attribute that
> specifies the reporter of a task which is mapped to the Trac specific key
> TracTicket.Key.REPORTER by TracAttributeFactory.
>
> If you do not need rich editor support you can start out by extending
> AbstractTask first and open a web browser for editing tasks. In a second
> step you can implement an attribute factory, a task data handler and an
> editor factory which will add rich offline editing.
>
> Hope this helps.
>
> Steffen
>
>
>
>> Hi everyone,
>>
>> I'm implementing a connector for the origo project (origo.ethz.ch). So I
>> had a look at the trac connector which is mentioned several times on the
>> integrator wiki, but I'm confused with the represenation of tasks. To
>> me it appears that there are 3 different representations: First there is
>> TracTicket, then TaskData and at last TracTask - Can someone please
>> explain the rationale behind this? E.g. why is not always TracTask used
>> - is it only for UI purposes?
>>
>> Another question related to this: What is the AttributeFactory good for?
>>
>> Thanks for any help!
>>
>> Dennis
>>
>
>
Re: Representation of tasks in trac connector [message #584118 is a reply to message #34788] Thu, 01 November 2007 20:15 Go to previous message
Steffen Pingel is currently offline Steffen PingelFriend
Messages: 706
Registered: July 2009
Senior Member
This will largely depend on the remote interface of the repository. For
repositories that use SOAP the data classes can be generated. In the case
of Trac the advantage of having an implementation that is independent of
the Mylyn tasks framework makes it potentially reusable for other projects
as well. Also the additional data classes allow to abstract from underlying
access method. The web mode does not support offline/rich editing so it
does not make much sense to use task data there. AFAIK the Bugzilla
connector does not have a separate data structure but uses task data
directly.

Steffen


Eugene Kuleshov wrote:

>
> I am starting to wonder if connector should be using
> RepositoryTaskData for internal stuff instead of maintaining 3rd
> structure.
>
> regards,
> Eugene
>
>
> Steffen Pingel wrote:
>> Hi,
>>
>> you are right that there are three different ways a Trac task is
>> represented:
>>
>> - TracTicket: this is the representations retrieved from the Trac
>> repository. It is either created from the data received through XML-RPC
>> or from the web interface. This is part of a generic API for accessing
>> Trac repositories that does not depend on Mylyn (except for
>> org.eclipse.mylyn.web.core).
>>
>> - TracTask: represents the task information in the task list. This is
>> kept in memory at all times and contains information needed by Mylyn to
>> represent the task in the UI. TracTasks are updated from TracTickets or
>> from RepositoryTaskData (see TracRepositoryConnector.updateFrom*()).
>>
>> - RepositoryTaskData: used for offline editing and offline storage. Task
>> data stores all information about a task in RepositoryTaskAttribute
>> objects. These are used by the editor to create widgets for editing,
>> determine incoming changes etc. RepositoryTaskData is created in
>> TracTaskDataHandler from TracTickets.
>>
>> AttributeFactory is used to map Mylyn's data model to a repository
>> connector specific model. For example Mylyn uses the
>> RepositoryTaskAttribute.USER_REPORTER key as the id for the attribute
>> that specifies the reporter of a task which is mapped to the Trac
>> specific key TracTicket.Key.REPORTER by TracAttributeFactory.
>>
>> If you do not need rich editor support you can start out by extending
>> AbstractTask first and open a web browser for editing tasks. In a second
>> step you can implement an attribute factory, a task data handler and an
>> editor factory which will add rich offline editing.
>>
>> Hope this helps.
>>
>> Steffen
>>
>>
>>
>>> Hi everyone,
>>>
>>> I'm implementing a connector for the origo project (origo.ethz.ch). So I
>>> had a look at the trac connector which is mentioned several times on the
>>> integrator wiki, but I'm confused with the represenation of tasks. To
>>> me it appears that there are 3 different representations: First there is
>>> TracTicket, then TaskData and at last TracTask - Can someone please
>>> explain the rationale behind this? E.g. why is not always TracTask used
>>> - is it only for UI purposes?
>>>
>>> Another question related to this: What is the AttributeFactory good for?
>>>
>>> Thanks for any help!
>>>
>>> Dennis
>>>
>>
>>
Re: Representation of tasks in trac connector [message #584428 is a reply to message #34822] Mon, 05 November 2007 10:17 Go to previous message
Eclipse UserFriend
Originally posted by: googelybear.gmail.com

First of all, thanks a lot for your explanations and taking the time to
write it all down, it gave me quite some insight.

In the long run I need rich editing support, but it would be very
helpful if I could create a first implementation which uses the existing
web ui for editing and displays tasks in the task list, but I'm not sure
how exactly I can achieve this. For example the
AbstractRepositoryConnector.createTaskFromExistingId method already
requires a TaskDataHandler and TaskData - or can I simply override this
and remove the indirection via TaskData?

I already created a subclass of the AbstractTask which adds the
connector specific fields. The UI plugin implements the ext point
org.eclipse.mylyn.tasks.ui.repositories (which means I created the 3
classes RepositoryConnector, connector ui and the tasklist factory). The
core plugin doesn't use any ext points.

What would be the next steps to create this first implementation?

Two more questions:

1. Am I right, that the TracTaskDataHandler and the attribute factory
are wokring in tandem to populate TaskData objects?

2. In the AbstractTask there is a field "taskId" - should this only be
used internally by mylyn or can I use it to store the external id of an
issue (the one which is also perceptible from the web ui, like the bug
id from bugzilla)?

Thanks again!

Dennis

Steffen Pingel wrote:
> This will largely depend on the remote interface of the repository. For
> repositories that use SOAP the data classes can be generated. In the case
> of Trac the advantage of having an implementation that is independent of
> the Mylyn tasks framework makes it potentially reusable for other projects
> as well. Also the additional data classes allow to abstract from underlying
> access method. The web mode does not support offline/rich editing so it
> does not make much sense to use task data there. AFAIK the Bugzilla
> connector does not have a separate data structure but uses task data
> directly.
>
> Steffen
>
>
> Eugene Kuleshov wrote:
>
>> I am starting to wonder if connector should be using
>> RepositoryTaskData for internal stuff instead of maintaining 3rd
>> structure.
>>
>> regards,
>> Eugene
>>
>>
>> Steffen Pingel wrote:
>>> Hi,
>>>
>>> you are right that there are three different ways a Trac task is
>>> represented:
>>>
>>> - TracTicket: this is the representations retrieved from the Trac
>>> repository. It is either created from the data received through XML-RPC
>>> or from the web interface. This is part of a generic API for accessing
>>> Trac repositories that does not depend on Mylyn (except for
>>> org.eclipse.mylyn.web.core).
>>>
>>> - TracTask: represents the task information in the task list. This is
>>> kept in memory at all times and contains information needed by Mylyn to
>>> represent the task in the UI. TracTasks are updated from TracTickets or
>>> from RepositoryTaskData (see TracRepositoryConnector.updateFrom*()).
>>>
>>> - RepositoryTaskData: used for offline editing and offline storage. Task
>>> data stores all information about a task in RepositoryTaskAttribute
>>> objects. These are used by the editor to create widgets for editing,
>>> determine incoming changes etc. RepositoryTaskData is created in
>>> TracTaskDataHandler from TracTickets.
>>>
>>> AttributeFactory is used to map Mylyn's data model to a repository
>>> connector specific model. For example Mylyn uses the
>>> RepositoryTaskAttribute.USER_REPORTER key as the id for the attribute
>>> that specifies the reporter of a task which is mapped to the Trac
>>> specific key TracTicket.Key.REPORTER by TracAttributeFactory.
>>>
>>> If you do not need rich editor support you can start out by extending
>>> AbstractTask first and open a web browser for editing tasks. In a second
>>> step you can implement an attribute factory, a task data handler and an
>>> editor factory which will add rich offline editing.
>>>
>>> Hope this helps.
>>>
>>> Steffen
>>>
>>>
>>>
>>>> Hi everyone,
>>>>
>>>> I'm implementing a connector for the origo project (origo.ethz.ch). So I
>>>> had a look at the trac connector which is mentioned several times on the
>>>> integrator wiki, but I'm confused with the represenation of tasks. To
>>>> me it appears that there are 3 different representations: First there is
>>>> TracTicket, then TaskData and at last TracTask - Can someone please
>>>> explain the rationale behind this? E.g. why is not always TracTask used
>>>> - is it only for UI purposes?
>>>>
>>>> Another question related to this: What is the AttributeFactory good for?
>>>>
>>>> Thanks for any help!
>>>>
>>>> Dennis
>>>>
>>>
>
Re: Representation of tasks in trac connector [message #584515 is a reply to message #35526] Mon, 05 November 2007 21:53 Go to previous message
Steffen Pingel is currently offline Steffen PingelFriend
Messages: 706
Registered: July 2009
Senior Member
> In the long run I need rich editing support, but it would be very
> helpful if I could create a first implementation which uses the existing
> web ui for editing and displays tasks in the task list, but I'm not sure
> how exactly I can achieve this. For example the
> AbstractRepositoryConnector.createTaskFromExistingId method already
> requires a TaskDataHandler and TaskData - or can I simply override this
> and remove the indirection via TaskData?

Yes, you should override this method and provide an implementation that
returns a task object of your connector specific class. The properties on
the task object should be updated from the repository in that method.

> I already created a subclass of the AbstractTask which adds the
> connector specific fields. The UI plugin implements the ext point
> org.eclipse.mylyn.tasks.ui.repositories (which means I created the 3
> classes RepositoryConnector, connector ui and the tasklist factory). The
> core plugin doesn't use any ext points.
>
> What would be the next steps to create this first implementation?

That sounds great. The next step is to implement querying support. That
involves implementing a wizard that is returned by
AbstractRepositoryConnectorUi.getQueryWizard() and implementing the query
logic in AbstractRepositoryConnector.performQuery().

> 1. Am I right, that the TracTaskDataHandler and the attribute factory
> are wokring in tandem to populate TaskData objects?

Yes, that is correct. The attribute factory is mostly used for the attribute
key mapping.

> 2. In the AbstractTask there is a field "taskId" - should this only be
> used internally by mylyn or can I use it to store the external id of an
> issue (the one which is also perceptible from the web ui, like the bug
> id from bugzilla)?

Each task needs to have a key that uniquely identifies that task in the
repository and never changes. You are right that the Bugzilla connector
uses the bug id that is also visible in the web ui. There is a second field
named taskKey that can be used to store a more descriptive identifier that
may change (e.g. JIRA uses that). The taskKey is used when Mylyn displays
the task id in the UI.

Steffen
Re: Representation of tasks in trac connector [message #584575 is a reply to message #35712] Wed, 07 November 2007 13:59 Go to previous message
Eclipse UserFriend
Originally posted by: googelybear.gmail.com

Ok great, I think I now got everything together to retrieve existing
tasks when the task id is provided. But when I righ-click on the
repository and select "open repository task" and enter an id it says
"could not find mathcing repository task". I already started eclipse in
debug mode and played around with brakpoints, but I couldn't figure out
which method of my connector gets called when I press "ok". Can you give
me a hint here?

thanks again,
Dennis

Steffen Pingel wrote:
>> In the long run I need rich editing support, but it would be very
>> helpful if I could create a first implementation which uses the existing
>> web ui for editing and displays tasks in the task list, but I'm not sure
>> how exactly I can achieve this. For example the
>> AbstractRepositoryConnector.createTaskFromExistingId method already
>> requires a TaskDataHandler and TaskData - or can I simply override this
>> and remove the indirection via TaskData?
>
> Yes, you should override this method and provide an implementation that
> returns a task object of your connector specific class. The properties on
> the task object should be updated from the repository in that method.
>
>> I already created a subclass of the AbstractTask which adds the
>> connector specific fields. The UI plugin implements the ext point
>> org.eclipse.mylyn.tasks.ui.repositories (which means I created the 3
>> classes RepositoryConnector, connector ui and the tasklist factory). The
>> core plugin doesn't use any ext points.
>>
>> What would be the next steps to create this first implementation?
>
> That sounds great. The next step is to implement querying support. That
> involves implementing a wizard that is returned by
> AbstractRepositoryConnectorUi.getQueryWizard() and implementing the query
> logic in AbstractRepositoryConnector.performQuery().
>
>> 1. Am I right, that the TracTaskDataHandler and the attribute factory
>> are wokring in tandem to populate TaskData objects?
>
> Yes, that is correct. The attribute factory is mostly used for the attribute
> key mapping.
>
>> 2. In the AbstractTask there is a field "taskId" - should this only be
>> used internally by mylyn or can I use it to store the external id of an
>> issue (the one which is also perceptible from the web ui, like the bug
>> id from bugzilla)?
>
> Each task needs to have a key that uniquely identifies that task in the
> repository and never changes. You are right that the Bugzilla connector
> uses the bug id that is also visible in the web ui. There is a second field
> named taskKey that can be used to store a more descriptive identifier that
> may change (e.g. JIRA uses that). The taskKey is used when Mylyn displays
> the task id in the UI.
>
> Steffen
Re: Representation of tasks in trac connector [message #584604 is a reply to message #35882] Thu, 08 November 2007 14:08 Go to previous message
Eclipse UserFriend
Originally posted by: googelybear.gmail.com

After a while I figured it out by myself, the method that gets called is
TaskUiUtils.openRepositoryTask. But now I'm stuck with the opposite
problem: How can I signal that a task, given its id entered in the "open
repo task" dialog box, does not exist?

The error msg "Could not find matching repository task." appears if
TasksUiUtil.openRepositoryTask returns false. Unfortunately I could not
find the "proper" way or place to achieve this (it must be somewhere
before the OpenRepositoryTaskJob is started, but to find out if a
certain task exists I would have to communicate with the repository...).

Thanks for any help,
Dennis


Dennis R. wrote:
> Ok great, I think I now got everything together to retrieve existing
> tasks when the task id is provided. But when I righ-click on the
> repository and select "open repository task" and enter an id it says
> "could not find mathcing repository task". I already started eclipse in
> debug mode and played around with brakpoints, but I couldn't figure out
> which method of my connector gets called when I press "ok". Can you give
> me a hint here?
>
> thanks again,
> Dennis
>
> Steffen Pingel wrote:
>>> In the long run I need rich editing support, but it would be very
>>> helpful if I could create a first implementation which uses the existing
>>> web ui for editing and displays tasks in the task list, but I'm not sure
>>> how exactly I can achieve this. For example the
>>> AbstractRepositoryConnector.createTaskFromExistingId method already
>>> requires a TaskDataHandler and TaskData - or can I simply override this
>>> and remove the indirection via TaskData?
>>
>> Yes, you should override this method and provide an implementation that
>> returns a task object of your connector specific class. The properties on
>> the task object should be updated from the repository in that method.
>>
>>> I already created a subclass of the AbstractTask which adds the
>>> connector specific fields. The UI plugin implements the ext point
>>> org.eclipse.mylyn.tasks.ui.repositories (which means I created the 3
>>> classes RepositoryConnector, connector ui and the tasklist factory). The
>>> core plugin doesn't use any ext points.
>>>
>>> What would be the next steps to create this first implementation?
>>
>> That sounds great. The next step is to implement querying support. That
>> involves implementing a wizard that is returned by
>> AbstractRepositoryConnectorUi.getQueryWizard() and implementing the query
>> logic in AbstractRepositoryConnector.performQuery().
>>
>>> 1. Am I right, that the TracTaskDataHandler and the attribute factory
>>> are wokring in tandem to populate TaskData objects?
>>
>> Yes, that is correct. The attribute factory is mostly used for the
>> attribute
>> key mapping.
>>
>>> 2. In the AbstractTask there is a field "taskId" - should this only be
>>> used internally by mylyn or can I use it to store the external id of an
>>> issue (the one which is also perceptible from the web ui, like the bug
>>> id from bugzilla)?
>>
>> Each task needs to have a key that uniquely identifies that task in the
>> repository and never changes. You are right that the Bugzilla connector
>> uses the bug id that is also visible in the web ui. There is a second
>> field
>> named taskKey that can be used to store a more descriptive identifier
>> that
>> may change (e.g. JIRA uses that). The taskKey is used when Mylyn displays
>> the task id in the UI.
>> Steffen
Re: Representation of tasks in trac connector [message #584786 is a reply to message #35951] Fri, 16 November 2007 18:20 Go to previous message
Steffen Pingel is currently offline Steffen PingelFriend
Messages: 706
Registered: July 2009
Senior Member
> The error msg "Could not find matching repository task." appears if
> TasksUiUtil.openRepositoryTask returns false. Unfortunately I could not
> find the "proper" way or place to achieve this (it must be somewhere
> before the OpenRepositoryTaskJob is started, but to find out if a
> certain task exists I would have to communicate with the repository...).

You need to throw a CoreException from
AbstractRepositoryConnector.createTaskFromExistingId() or
AbstractTaskDataHandler.getTaskData() in case an invalid ticket id is
requested. OpenRepositoryTaskJob will catch that exception and display an
error dialog.

Steffen
Re: Representation of tasks in trac connector [message #584896 is a reply to message #36322] Mon, 19 November 2007 15:48 Go to previous message
Eclipse UserFriend
Originally posted by: googelybear.gmail.com

Hi Steffen,

Thanks for your tip, the error msg is now correctly displayed. I will
post a follow up question in a separate post.

Dennis

Steffen Pingel wrote:
>> The error msg "Could not find matching repository task." appears if
>> TasksUiUtil.openRepositoryTask returns false. Unfortunately I could not
>> find the "proper" way or place to achieve this (it must be somewhere
>> before the OpenRepositoryTaskJob is started, but to find out if a
>> certain task exists I would have to communicate with the repository...).
>
> You need to throw a CoreException from
> AbstractRepositoryConnector.createTaskFromExistingId() or
> AbstractTaskDataHandler.getTaskData() in case an invalid ticket id is
> requested. OpenRepositoryTaskJob will catch that exception and display an
> error dialog.
>
> Steffen
>
Previous Topic:Huge context file after CVS Checkout causes Eclipse to hang
Next Topic:Generic Web Connection Query
Goto Forum:
  


Current Time: Wed Apr 24 22:11:08 GMT 2024

Powered by FUDForum. Page generated in 0.04982 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top