Home » Eclipse Projects » Eclipse Platform » Content types, contentTypeBinding
| Content types, contentTypeBinding [message #322386] |
Thu, 15 November 2007 10:51  |
Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------020001090701020109080300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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#interna lFindContentTypesFor(org.eclipse.core.internal.content.Conte ntTypeMatcher,
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
--------------020001090701020109080300
Content-Type: text/x-vcard; charset=utf-8;
name="laurent.goubet.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="laurent.goubet.vcf"
begin:vcard
fn:Laurent Goubet
n:Goubet;Laurent
org:Obeo
email;internet:laurent.goubet@obeo.fr
url:http://www.obeo.fr
version:2.1
end:vcard
--------------020001090701020109080300--
|
|
|
| Re: Content types, contentTypeBinding [message #322387 is a reply to message #322386] |
Thu, 15 November 2007 11:10  |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------050405010108070004090202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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$Des criber ">
<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#interna lFindContentTypesFor(org.eclipse.core.internal.content.Conte ntTypeMatcher,
> 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
--------------050405010108070004090202
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Laurent,<br>
<br>
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.<br>
<br>
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.<br>
<blockquote><small> <extension</small><br>
<small> point="org.eclipse.core.runtime.contentTypes"></small ><br>
<small> <content-type</small><br>
<small> base-type="org.eclipse.core.runtime.xml"</small><br>
<small> file-extensions="ecore,xmi"</small><br>
<small> id="org.eclipse.emf.ecore"</small><br>
<small> name="%_UI_Ecore_content_type"</small><br>
<small> priority="normal"></small><br>
<small> <describer</small><br>
<small>
class=" org.eclipse.emf.ecore.xmi.impl.RootXMLContentHandlerImpl$Des criber "></small><br>
<small> <parameter</small><br>
<small> name="namespace"</small><br>
<small>
value=<a class="moz-txt-link-rfc2396E" href="http://www.eclipse.org/emf/2002/Ecore">"http://www.eclipse.org/emf/2002/Ecore"</a>></small><br>
<small> </parameter></small><br>
<small> <parameter</small><br>
<small> name="kind"</small><br>
<small> value="xmi"></small><br>
<small> </parameter></small><br>
<small> </describer></small><br>
<small> </content-type></small><br>
<small> </extension></small><br>
</blockquote>
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...<br>
<br>
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...<br>
<br>
<br>
laurent Goubet wrote:
<blockquote cite="mid:fhhppv$qm5$1@build.eclipse.org" type="cite">Hi
all,
<br>
<br>
I've been searching through google, this newsgroup, some javadoc and
the content type implementation code, but couldn't get an answer for
this.
<br>
<br>
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.
<br>
<br>
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 "*".
<br>
<br>
org.eclipse.core.internal.content.ContentTypeCatalog#interna lFindContentTypesFor(org.eclipse.core.internal.content.Conte ntTypeMatcher,
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.
<br>
<br>
Regards,
<br>
Laurent Goubet
<br>
Obeo
<br>
</blockquote>
<br>
</body>
</html>
--------------050405010108070004090202--
|
|
| |
| Re: Content types, contentTypeBinding [message #322391 is a reply to message #322388] |
Thu, 15 November 2007 12:40 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------080602010100060601090702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Laurent,
We also have an extension point that registers only with EMF so that one
is more flexible, but indeed does not solve your problem:
<extension-point id="content_handler"
name="%_UI_ContentHandlerRegistry_extensionpoint"
schema="schema/content_handler.exsd" />
And yes, when accessing the content type directly through the resource
API it is indeed cached so that helps with performance a great deal but
results in another problem: when new content types are introduced, the
cached value is not recomputed. Of course for EMF standalone support, I
couldn't rely on caching...
Perhaps you should open a bugzilla enhancement request to ask for what
you want. And if you really want it to happen, you could perhaps
prototype the changes that are needed...
laurent Goubet wrote:
> Ed,
>
> This could be quite interesting indeed, yet your implementation also
> depends on the "org.eclipse.core.runtime.contentTypes" extension
> points which only allows registering of describers against either a
> filename or a file extension (of course, you can put "*" or leave
> those empty, but eclipse will then only ignore your describer).
>
> What I am really looking for is to have a describer for anything (as I
> said, I can very well create an xmi file and call it foo.bar). Your
> point stil remains then : every describer for every plugin will then
> parse the file, resulting in a heavier load. Yet since Eclipse caches
> the content type of the files (or so do I think), I don't think the
> load is such an issue.
>
> Ed Merks a
|
|
| |
| Re: Content types, contentTypeBinding [message #322393 is a reply to message #322392] |
Thu, 15 November 2007 13:24 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Laurent,
I imagine that only of the two is required but not both, so marking
either as required would be wrong. So they're both marked optional with
the inexpressible constraint that one of the two must be specified.
laurent Goubet wrote:
> And yet I wonder if this is indeed an enhancement or a bug. If this is
> an enhancement, why wouldn't the "filename" and "file extension" of
> "org.eclipse.core.runtime.contentTypes" extension point be required
> fields?
>
> Leaving those two fields optional means (or at least, I *think* it
> means) that eclipse will not just ignore my Describer if I do let them
> empty or filled as "*".
>
> As for trying and prototype it, well, why not if I can find time
> (okay, everyone uses this very same excuse ^^). But I would at least
> need to know why the aforementionned fields are ignored when leaved as
> default. This might be a well-thought feature :p.
>
> Ed Merks a écrit :
>> Laurent,
>>
>> We also have an extension point that registers only with EMF so that
>> one is more flexible, but indeed does not solve your problem:
>>
>> <extension-point id="content_handler"
>> name="%_UI_ContentHandlerRegistry_extensionpoint"
>> schema="schema/content_handler.exsd" />
>>
>> And yes, when accessing the content type directly through the
>> resource API it is indeed cached so that helps with performance a
>> great deal but results in another problem: when new content types are
>> introduced, the cached value is not recomputed. Of course for EMF
>> standalone support, I couldn't rely on caching...
>>
>> Perhaps you should open a bugzilla enhancement request to ask for
>> what you want. And if you really want it to happen, you could
>> perhaps prototype the changes that are needed...
>>
>>
>> laurent Goubet wrote:
>>> Ed,
>>>
>>> This could be quite interesting indeed, yet your implementation also
>>> depends on the "org.eclipse.core.runtime.contentTypes" extension
>>> points which only allows registering of describers against either a
>>> filename or a file extension (of course, you can put "*" or leave
>>> those empty, but eclipse will then only ignore your describer).
>>>
>>> What I am really looking for is to have a describer for anything (as
>>> I said, I can very well create an xmi file and call it foo.bar).
>>> Your point stil remains then : every describer for every plugin will
>>> then parse the file, resulting in a heavier load. Yet since Eclipse
>>> caches the content type of the files (or so do I think), I don't
>>> think the load is such an issue.
>>>
>>> Ed Merks a écrit :
>>>> 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$Des criber ">
>>>>
>>>> <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#interna lFindContentTypesFor(org.eclipse.core.internal.content.Conte ntTypeMatcher,
>>>>> 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
>>>>
>>>
>>
>
|
|
|
Goto Forum:
Current Time: Tue Sep 16 10:43:41 EDT 2025
Powered by FUDForum. Page generated in 0.06813 seconds |
Home