Laurent,
I found the platform's content type support a little frustrating. Sorry
don't shoot me anyone! It seems to me that if there were 100 different
XML content types, each describer would reparse the file (using a newly
created SAX parser which is shockingly expensive to create), so you'd
parse the darned thing 100 times creating 100 parsers. And of course
you still have to explicitly indicate which extensions the content type
applies to so you've still not freed yourself from dependencies on
extensions, which is one of the main points of supporting content types.
If you look at EMF 2.4's new content type support, you'll see that we
try to address some of these issues, and of course we have taken the
usual approach of providing APIs that work both stand alone and
integrate with Eclipse's APIs when running in an Eclipse context. With
this approach, the content of a file will be parsed just once, and then
each "describer" i.e., each ContentHandler, can inspect it to see if it
matches the type of content that it expects. The following
registration in the XMI plugin.xml shows how you can register a content
type that's implemented using EMF's content handler mechanism.
<extension
point="org.eclipse.core.runtime.contentTypes">
<content-type
base-type="org.eclipse.core.runtime.xml"
file-extensions="ecore,xmi"
id="org.eclipse.emf.ecore"
name="%_UI_Ecore_content_type"
priority="normal">
<describer
class="org.eclipse.emf.ecore.xmi.impl.RootXMLContentHandlerImpl$Describer">
<parameter
name="namespace"
value="http://www.eclipse.org/emf/2002/Ecore">
</parameter>
<parameter
name="kind"
value="xmi">
</parameter>
</describer>
</content-type>
</extension>
With the new URIConverter APIs, you can register a content handler
against "*", but if the platform doesn't support that, this won't
really help with the editor problem. Hopefully my answer doesn't cut
off comments about your platform part of the question...
Of course, being EMF, the documentation is sadly lagging the code, so
documentation is effectively nonexistent. I really need to write some,
but there are so many other pressures. Feedback on using the design
would be much appreciated...
laurent Goubet wrote:
Hi
all,
I've been searching through google, this newsgroup, some javadoc and
the content type implementation code, but couldn't get an answer for
this.
I developped an editor and would like to define dynamically which files
it must handle. Thus I created a ContentTypeDescriber who'll be able to
do this ... Only to realize it's "describe" methods are never called
... after doing a little debugging through ContentTypeCatalog and the
such, I finally found why : I would like my editor to be associated
with any file containing XML content, but I *do not know* either the
file name or the file extension.
As an example, a file called "foo.bar" or even "cock-a-doodle.doo"
could very well contain xml content and thus could be opened as such.
The actual implementation for content type binding within eclipse will
never call a ContentTypeDescriber's "describe" method if we have
defined it to be associated to filename "*" and file extension "*".
org.eclipse.core.internal.content.ContentTypeCatalog#internalFindContentTypesFor(org.eclipse.core.internal.content.ContentTypeMatcher,
java.lang.String, java.util.Comparator) is in charge of finding the
content type for a given file name. It will try to find a content type
for : 1) the file name, 2) the file extension. Wouldn't it be possible
to search for the "generic" content types too? This would at the same
time allow us to get a content-type describer to try and describe files
with no extension.
Regards,
Laurent Goubet
Obeo
|