Summary: | [Model API] Accomodate models localized to files | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Michael Valenta <Michael.Valenta> |
Component: | Team | Assignee: | Platform Team Inbox <platform-team-inbox> |
Status: | ASSIGNED --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P5 | CC: | dirk_baeumer, n.a.edgar |
Version: | 3.2 | Keywords: | helpwanted |
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Michael Valenta
2005-11-02 06:19:30 EST
Dirk, do you have any ideas about this? Also, I'm curious to know if JDT has any API related to properties files. Does JDT and PDE share a model now the PDE supports NLSing? Michael, I second the idea of having "content type models". We have requests especially for JDT to be able to show the content of ANT files inside the package explorer. I discussed this with Michael Elder on the last Common Navigator call and he said that should be doable inside the Common Navigator framework. However have this more general in the workbench will make sure that views not "reusing" parts of the common navigator can profit from this as well. I already do something similar in LTK to provide the preview for refactorings. The upper tree of the preview page contains language specific nodes (for example if you change a compilation unit you see types and methods as sub nodes). This is open to other languages. The can provide their own tree nodes depending on the language they are changing. Regarding properties: JDT/UI has a model, but it is not API. It lives in core refactoring (PropertyFileDocumentModel). We don't share this code with PDE right now. Nick, do you have any thoughts on this? I think this is a reasonable scenario. Although I know you just used the *.properties files as an example, I've asked Steve Wasleski for more details on how the translators actually work, and whether special handling of *.properties files would be desired. E.g. if I change Fred.properties and commit it, the user should be warned if there are also changes to a Fred.properties_Fr_fr file. The logical model element "Fred.properties and its translations" is 1:N and open-ended. If we match model providers on criteria other than project nature, though, it does imply that if we do an operation on a project or folder, we need to walk the tree and search for all matching model providers. No time left in 3.2 to look at this. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. |