Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mylyn-integrators] help with displaying task in editor

Good idea Mik. I added slightly edited snippet from my first email to
http://wiki.eclipse.org/Mylyn/Integrator_Reference#Task_editor

-Peter

On Wed, Mar 25, 2009 at 3:01 AM, Mik Kersten <mik@xxxxxxxxxxx> wrote:
> Just wanted to mention that it's great to see integrators supporting each
> other this way on the list.  If either of you can spare time to capture
> these tips on the integrator reference for others to refer to, that would be
> fantastic, and it only takes a few moments to post your additions:
> http://wiki.eclipse.org/index.php/Mylyn/Integrator_Reference
>
> Significant parts of that document have been contributed by first-time
> integrators, so please don't be shy about adding content, as we review all
> changes and fix up as needed.
>
> Mik
>
>> -----Original Message-----
>> From: mylyn-integrators-bounces@xxxxxxxxxxx [mailto:mylyn-integrators-
>> bounces@xxxxxxxxxxx] On Behalf Of Peter Stibrany
>> Sent: Tuesday, March 24, 2009 12:28 PM
>> To: Mylyn Integrators list
>> Subject: Re: [mylyn-integrators] help with displaying task in editor
>>
>> Hi Larry,
>>
>> I think it is good strategy to use existing parts -- it will save you
>> lot of time (I think I use only one custom part, all others are
>> default). But sometimes you may need something extra (different
>> behaviour, UI, ...) -- in this case, custom part can also be good way
>> to achieve what you want.
>>
>> For attributes, I mostly use attributes with custom IDs. You can then
>> map Mylyn attribute names to your attributes (see TaskAttributeMapper
>> class, and subclasses in different connectors).
>>
>> -Peter
>>
>> On Tue, Mar 24, 2009 at 8:16 PM, Larry Edelstein
>> <ledelstein@xxxxxxxxxxxxxx> wrote:
>> > Thanks Peter.  You've already put me on the right path - before, I
>> wasn't adding the type metadata to the attributes I was creating.
>> >
>> > What I'm wondering: is it a good strategy to just use the existing
>> attribute names, and the existing parts?  Assuming I can reverse-
>> engineer the code and figure out which attributes to use for each
>> parts, I ought to be able to build a pretty good task editor just from
>> those...right?
>> >
>> > -larry
>> >
>> > -----Original Message-----
>> > From: mylyn-integrators-bounces@xxxxxxxxxxx [mailto:mylyn-
>> integrators-bounces@xxxxxxxxxxx] On Behalf Of Peter Stibrany
>> > Sent: Monday, March 23, 2009 1:42 PM
>> > To: Mylyn Integrators list
>> > Subject: Re: [mylyn-integrators] help with displaying task in editor
>> >
>> > Hello,
>> >
>> > as you found out, task editor consists of various sections (editor
>> > parts). Task editor (or better TaskEditorAttributePart, displayed as
>> > "Attributes" section) can display and edit any of your attributes. It
>> > will use attribute metadata to determine whether to show your
>> > attribute or not and to choose correct widget (textfield, combobox,
>> > ...).
>> >
>> > Here is sample code to create
>> >
>> > public TaskAttribute createAttribute(TaskData data, String keyID,
>> > String attrType, boolean isVisible, String label, boolean readOnly) {
>> >        TaskAttribute attr = data.getRoot().createAttribute(keyID);
>> >
>> >        TaskAttributeMetaData metaData = attr.getMetaData();
>> >        metaData.setType(attrType);
>> >        metaData.setKind(isVisible ? TaskAttribute.KIND_DEFAULT :
>> null);
>> >        metaData.setLabel(label);
>> >        metaData.setReadOnly(readOnly);
>> >
>> >        return attr;
>> > }
>> >
>> > where
>> >
>> > KeyID is any unique ID string. In Foglyn I use FogBugz field names
>> > (e.g. "fb_ixPriority").
>> >
>> > AttrType can be one of TaskAttribute.TYPE_* constants, or your custom
>> > constant. Type determines widget (subclasses of
>> > AbstractAttributeEditor) to be created. You can have custom editors
>> > too (in this case you'll need to use custom AttributeEditorFactory,
>> > and return it from your AbstractTaskEditorPage subclass).
>> >
>> > isVisible determines whether attribute should be displayed in task
>> > editor or not. Invisible attributes are useful for storing data in a
>> > task which you don't want to present to user.
>> >
>> > readOnly is clear. When true, read-only editor is created for
>> > attribute, i.e. user cannot change it in task editor.
>> >
>> > I found little documentation about which section uses which
>> > attributes. Fortlynately, there is source for everything, although
>> > this part of Mylyn is quite over-engineered, and I always get lost
>> > when looking into it. I think your only way is to look into what
>> > sections (editor parts) are available (subclasses of
>> > AbstractTaskEditorPart), and look into classes which sound like good
>> > candidates (people, comments, attachment, planning, ...) to see what
>> > attributes they use :-(
>> >
>> > -Peter Stibrany
>> > www.foglyn.com
>> >
>> > On Mon, Mar 23, 2009 at 8:32 PM, Larry Edelstein
>> > <ledelstein@xxxxxxxxxxxxxx> wrote:
>> >> I've been working on a Mylyn connector and would like some help
>> regarding
>> >> how to display my task in a task editor page.  My connector pulls
>> down data
>> >> from our database just fine, and I expect that pushing back to the
>> database
>> >> will also go smoothly.  I'm a little uncertain of my strategy and
>> tactics
>> >> for displaying data in a task editor.  I want to reuse
>> >> AbstractTaskEditorPage and the various AbstractTaskEditorPart
>> subclasses.  I
>> >> can see that I can configure my page subclass to use which parts I
>> want.  So
>> >> far I'm just using the page as is.  But when I run my connector, I
>> don't see
>> >> the data I expect in the page.
>> >>
>> >>
>> >>
>> >> What should be my strategy for reusing the page and parts?  Is it
>> merely to
>> >> make sure that I map the data from my database into the correct
>> attributes
>> >> for the parts?  If so, how do I know which attributes, and which
>> parts
>> >> display themselves on the page (by default)?  By reading and tracing
>> the
>> >> code, I thought I had found the right parts and attributes, but I'm
>> >> disappointed in my results.
>> >>
>> >>
>> >>
>> >> Not to put too fine a point on it, but I have a demo on Wednesday
>> morning.
>> >> Showing more results then would be very timely for this project.  If
>> I can
>> >> get some guidance on how to carry out the strategy I've described,
>> or a
>> >> better one, it would really help.
>> >>
>> >>
>> >>
>> >> Regards,
>> >>
>> >>
>> >>
>> >> Larry Edelstein
>> >>
>> >> Senior Member of Technical Staff
>> >>
>> >> salesforce.com
>> >>
>> >> (415) 713-9148
>> >>
>> >> ledelstein@xxxxxxxxxxxxxx
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> mylyn-integrators mailing list
>> >> mylyn-integrators@xxxxxxxxxxx
>> >> https://dev.eclipse.org/mailman/listinfo/mylyn-integrators
>> >>
>> >>
>> > _______________________________________________
>> > mylyn-integrators mailing list
>> > mylyn-integrators@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/mylyn-integrators
>> > _______________________________________________
>> > mylyn-integrators mailing list
>> > mylyn-integrators@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/mylyn-integrators
>> >
>> _______________________________________________
>> mylyn-integrators mailing list
>> mylyn-integrators@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/mylyn-integrators
>
> _______________________________________________
> mylyn-integrators mailing list
> mylyn-integrators@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylyn-integrators
>


Back to the top