| Summary: | allow import/export and cloning of queries | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Jason van Zyl <jason-eclipse> | ||||||
| Component: | Mylyn | Assignee: | Jevgeni Holodkov <jevgeni.holodkov> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | enhancement | ||||||||
| Priority: | P2 | CC: | ekuleshov, robert.elves | ||||||
| Version: | dev | Keywords: | helpwanted | ||||||
| Target Milestone: | --- | ||||||||
| Hardware: | Macintosh | ||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Jason van Zyl
It would be cool if we could hook up special org.eclipse.swt.dnd.Transfer so one could copy/paste and drag&drop query nodes even outside Eclipse, i.e. drag query node into email message to create attachment, that could use same format that Task List export/import wizard is using. Yes, I think that we should be able to import/export any element that shows up in the Task List either via explicit import/export or via drag-and-drop. Then an operation like copy/pase of a query could support this use case. I think that we can chalk this up to new user experience, which flexible and easier query creation is a part of. Bug 189518 is releated. Jevgeni: this is closely related to bug 178883 and will support use cases such as dragging a query to an IM client and then back into Eclipse. This is more closely related to collaboration than New User Experience so removing tag. To clarify the implementation details: I see at least two ways of cloning the query - either serialization and deserialization to/from the file to a new Query or implementing a clone() method in *RepositoryQueries where needed (or making abstract createCopy() in AbstractRepositoryQuery). I would prefer the second option, but what do you think about it? (In reply to comment #4) > To clarify the implementation details: [cut] I would prefer the > second option, but what do you think about it? Task List externalizers (actually subclasses of the AbstractTaskListFactory) already know how to read and write query configuration. See also TaskListWriter and DelegatingTaskExternalizer. (In reply to comment #5) > Task List externalizers (actually subclasses of the AbstractTaskListFactory) > already know how to read and write query configuration. See also TaskListWriter > and DelegatingTaskExternalizer. Right, just to clarify - isn't the AbstractTaskListFactory using Element as a transfer object, so it will be more like "old query -> document with element -> new query" (more closer to the first option), rather than old query -> new query. If this variant is acceptable, I will go that way. Since you will be effectively calling AbstractTaskListFactory to get the Element and then convert it back to query it won't be a an issue. Adding clone() method to all connectors in not really an option for compatibility reasons (we can't add new API). (In reply to comment #7) > Adding clone() method to all connectors in not really an option for compatibility > reasons (we can't add new API). Eugene: we can add new API, but have to do so in a backwards compatible way: http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs Jevgeni: before adding or changing any method on API (i.e. a public type that's not in an internal package) please first post the reason for doing so on a bug report so that we can review it together. Created attachment 74482 [details]
Clone query UI
Also have created (extracted from a method insertQueries) an utility method resolveIdentifiersConflict in TaskListManager, that manages name conflicts, since name conflict should be resolved before the EditQuery dialog appears.
Created attachment 74483 [details]
mylyn/context/zip
Rob: please review. Works great! Patch applied and ip log updated. Tagged new TaskListManager.resolveIdentifiersConflict() method @since 2.1 and updated Mylyn porting guide. Changing OS from Mac OS to Mac OS X as per bug 185991 Is done by now. Let's open another task if needed. |