Community
Participate
Working Groups
It would be nice if RepositoryTaskAttribute supports also DatePicker (currently text field/single value and combo/option is supported). Then the date picker could be used do diplay/get/set connector specific dates (currently text field/single value has to be used) that are not covered in task planning stuff.
Lubos, are you talking about the new Date/Time control from Eclipse 3.3 (bug#19945)? If so, I think you'll have to wait until Mik decide to use 3.3 APIs. Anyway, once this is authorized, I think they will review every place where the custom date/time picker is used and replace with the SWT control.
No, I am talking about import org.eclipse.mylar.tasks.ui.DatePicker Mylar already uses in AbstractNewRepositoryEditor and in other places. It just would be handy to extend RepositoryTaskAttribute to support this DatePicker and Spinner so they can be used by connector developer for date or number data specific to connector. This has nothing to do with new Eclipse 3.3 date picker.
Ops, sorry!
No, that was good question. I should have clarify about which DatePicker I mean. BTW, if there is an interest, I can try to implement it and submit patch.
Lubos: I'm not quite sure what you mean by "extend RepositoryTaskAttribute to support this DatePicker", because RepositoryTaskAttribute is just a class that holds data, and the way that date attributes are created is a UI concern that's separate. Could you outline a concrete example of how you want this to work? Then I will be able to give you suggestoins for creating the patch.
OK, I think I know what you mean now: you probably want the attributes section of the task editor to support editing via a spinner and a date picker. That sounds good, and the one thing to keep in mind is that RepositoryTaskAttribute should not be changed to support this, since it should not know anything about UI. Since you're interested in providing a patch I'll assign to you for the time being.
*** Bug 170569 has been marked as a duplicate of this bug. ***
Mik, it may make sense to add something like "type" to RepositoryTaskAttribute. I.e. text, date, etc... Then UI can render the form based on the type information.
Mik, I am not sure how to implement it without changing RepositoryTaskAttribute. Of course I would retain all the current functionality and backward compatibility, but I would have to extend it either based on a type member variable as Eugene suggested or based on method calls (like it is done in case of options now). But because UI uses RepositoryTaskAttribute to create appropriate UI widgets for the attributes, RepositoryTaskAttribute should be extended to support spinner and date picker (and possibly more in the future...) and then the editor UI should make use of the extended RepositoryTaskAttribute functionality. Let me know if this suggestion makes sense.
Rob: you've been wrestling with this need to keep the data and presentation/editing separate, so please advise Lubos.
Lubos: Holding of options etc is what we want to eliminate from the RepositoryTaskData. The RepositoryTaskData ideally should only hold the data that represents the current state of a repository task (not options available per field, ie. spinner ranges, defaults etc). There are a few reasons for this: 1) bloat in offline storage 2) stale options ...among other reasons. To avoid these issues we've created the following tasks to pull this data out of RepoositoryTaskData: 150680: [api] Generalize repository configuration persistence and move into tasklist https://bugs.eclipse.org/bugs/show_bug.cgi?id=150680 Eventually options (spinner ranges etc) will come from RepositoryConfiguration when pulled up into tasks.core. Since options will become available from repositoryconfiguration, I imagine a mapping to type could happen there eliminating the need for a type on the repositoryTaskAttribtue as well no? Adding type to RepositorTaskAttribute may be a reasonable compromise though. Thoughts?
Eliminating RepositorTaskAttribute from RepositorTaskData or eliminating options from RepositorTaskAttribute means change in API and therefore no backward compatibility of the API. That is bad for connector developers, because they will have to modify, upgrade their connectors. Still both Spinner and DatePicker hold just one value (not a set of pssible option), so it does reflect the state of the repository task (unlike options). Simple adding setDate() and setNumber() would bew enough (the type can be maintained internally in RepositorTaskAttribute without caller setting it). Then UI would just check for date or number and create apropriate widget.
(In reply to comment #12) > Eliminating RepositorTaskAttribute from RepositorTaskData or eliminating options > from RepositorTaskAttribute means change in API and therefore no backward > compatibility of the API. That is bad for connector developers, because they > will have to modify, upgrade their connectors. Yes, if this change is to happen for 2.0 we will make the transition as easy as possible. > Still both Spinner and DatePicker hold just one value (not a set of pssible > option), so it does reflect the state of the repository task (unlike options). > Simple adding setDate() and setNumber() would bew enough (the type can be > maintained internally in RepositorTaskAttribute without caller setting it). > Then UI would just check for date or number and create appropriate widget. And what is the api call for this check for date or number (getType())?
Either with getType or based on data content like it is now (if (attribute.hasOptions() && !attribute.isReadOnly())). I would prefer getType().
Wouldn't getType() give you everything you need.... without the need for get/setDate get/setNumber? Then based on type we can interpret/display/update the attribute value appropriately. In the case of a date field we could use the ITaskDataHandler.getDateForAttributeType() method to extract a usable date?
getType() would be great. The type can be derived internally from data. RepositorTaskAttribute can support: setValue(String) setValue(Integer) setValue(Long) setValue(Double) setValue(Date) Based on the set value the type is assigned. Then UI can use getType() to decide which widget to render. For Spinner/number it would also be nice to be able to optionally set min, max and step: setMinValue() setMaxValue() setStepValue()
Longterm this may be the solution but short term would it be possible to do something along the lines of what we've done for Bugzilla time tracking? We override createCustomAttributeLayout and call BugzillaTaskEditor.addBugzillaTimeTracker() which renders the attributes (including date picker) as needed?
Rob, I do not have to have it right now. When developing the connector, I realized I cannot use the same UI widgets for date and number as the one used in planning section. In short term I can use text fields (single attribute value), but that doesn't have build in validation and it doesn't look as good. I would be happy to come up with patch for 2.0. I just need to know if it is OK to submit a patch and if the patch has fighting chance to being looked at 8-).
Lets wait till M1 is out then revisit this design discussion (setting target to M2). It's great that you are willing to contribute a patch for this! There are other bugs that we'll need to consider when when we revisit this. There are plans to refactor what RepositoryTaskData holds (as I mentioned above) and where configuration data is held (bug#150680) but we're also looking at how it is stored offline (bug#160389).
Lubos: note that this isn't about the Planning section, but about a custom section that appears under the attributes if the Bugzilla repository has time tracking enabled. You should be able to do something very similar for your custom attributes, and do things like your own range checking. Look through the bugzilla editor for time tracking stuff to get an idea of how it deals with these special attributes.
I was bringing up planning section as an example of the widgets, yes I do mean using it in attributes section. But by adding support to RepositorTaskAttribute for number, date, ... it makes it much easier for connector developer to use them (you do not need to subclass and do it yourself).
TaskData and offline refactoring scheduled for RC0
Support for date pickers has been added as part of the editor refactoring for 3.0. I haven't added support for spinners or a data type that accepts a range of integer values, yet. It's not overly complicated but I am not sure how well spinners render on forms and if this needs to be part of the framework or is better contributed by connectors. Are there other connectors that would benefit from support for spinners to edit task attributes?
I have removed the milestone for now. We can reconsider if there is indication that spinners should be provided as part of the standard attribute editor API.
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
