Community
Participate
Working Groups
Some models, such as *.properties (and perhaps *.settings files), are localized to the file that contains them. What this means is that these models can exist in any higher-level container structure (Resource folder structure or Java packages structure) and only really care about the contents of the file. as such, they really don't want to be a full blown model provider but instead want to provide model support only at the file level (i.e. content type or file association). Eclipse already supports this for the most part but we will want to make sure the support is complete and documented. Here's some exisiting support I can think of, off the top of my head. - auto-merge: IStreamMerger - manual-merge: IContentViewer - model rendering: IWorkbenchAdapter The last point is interesting. Currentlu, it uses the content type to get an appropriate icon. It could also yield a set of children that could be displayed in any view. This would have implications on performance and also on consistency That is, you could expand a properties file in the navigator but not files from higher level models (i.e. perhaps a Java file would only be expandable in Java views). This may be acceptable but if it wasn't, the ability to expand the contents could exist but not be used by the Resource Navigator. This would still allow higher level models such as Java to expand *.properties files in their views. We should work out some scenarios for this to see what makes sense.
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.
