[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
>
