This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | [devrev][mime-lookup]Support "compound" mime-types | ||
---|---|---|---|
Product: | editor | Reporter: | Jan Lahoda <jlahoda> |
Component: | -- Other -- | Assignee: | Martin Roskanin <mroskanin> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | apireviews, jglick |
Priority: | P1 | ||
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 20203 |
Description
Jan Lahoda
2005-06-20 13:25:44 UTC
I am not able to find sufficient info about "compound" mime-types on Inet. I have found RFC 3023: http://www.rfc-editor.org/rfc/rfc3023.txt that covers XML Media Types and these +xml types are specified there. Anyway, I haven't found a document that would standardize the global use of "+" in other mime types also. Thus I have following questions, maybe someone of you will know the answers: 1. In RFC 3023 document the "+xml" suffix convention is always in the way <something>+xml and not xml+<something>. However, I have noticed, that the mime type text/xml+ant is widely used in mailing lists, or e.g. in this issue instead of text/ant+xml. I would say, to ensure correct merging (inheritance of mime types), this needs to be unified. 2. Can such "compound" mime-type contain embeded mime types, e.g. Editors/text/ant+xml/text/dtd? (Similar as scriplet in JSP - Editors/text/jsp/text/x-java) 3. Is it possible to declare more suffixes like: text/ant+dtd+xml? Re. #1 - follow the RFC; other styles are presumably mistakes. The Ant module uses text/x-ant+xml which seems to comply with the RFC. Re. #2 - how would that work in practice? Re. #3 - I don't think so. >Re. #2 - how would that work in practice?
I am not aware of some use case. It would work similar like in JSP scriplet,
where java language can be embeded into jsp document - in this case for example
invoking context menu over scriplet will use the actions from jsp and some
(suitable in the scriplet context) actions from java. I just thought, that maybe
there can be some use case where "compound" mime-type can have embeded languages
as well.
fixed in [editor_api] /cvs/editor/mimelookup/src/org/netbeans/modules/editor/mimelookup/Attic/LayerFolderObjectsProvider.java,v <-- LayerFolderObjectsProvider.java new revision: 1.1.2.11; previous revision: 1.1.2.10 /cvs/editor/mimelookup/test/unit/src/org/netbeans/modules/editor/mimelookup/Attic/MimeLookupTest.java,v <-- MimeLookupTest.java new revision: 1.1.2.16; previous revision: 1.1.2.15 So... when this impl is merged, what will I be able to do that I cannot now? Specifically, can I now remove the line setMIMEType("text/xml"); from AntProjectDataEditor, and still have XML syntax coloring in the Ant editor, but also use Editors/text/x-ant+xml/Popup/*.instance to adjust the context menu? Yes. Objects in "text/xml" will be inherited, it means that for mime type "text/x-ant+xml" a Popup menu items will be represented as a compound of Editors/text/xml/Popup and Editors/text/x-ant+xml/Popup folder objects plus objects found in default Editors/Popup folder (there are actions like Cut, Copy, Paste...general for all editors) And as for #2: I implemented a generic mechanism for sub mime-types of "compound" mime-types so now it is possible to use even such nightmare as e.g.: Editors/text/ant+xml/text/dtd/text/dtd+xml/application/x-word... Great - let me know when it is in trunk. |