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 <[email protected]> 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: [email protected] > [mailto:[email protected]] 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 > <[email protected]> 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 >> >> [email protected] >> >> >> >> _______________________________________________ >> mylyn-integrators mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/mylyn-integrators >> >> > _______________________________________________ > mylyn-integrators mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/mylyn-integrators > _______________________________________________ > mylyn-integrators mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/mylyn-integrators > _______________________________________________ mylyn-integrators mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/mylyn-integrators
