[news.eclipse.platform] Re: Content types, contentTypeBinding

[laurent Goubet <laurent.goubet@xxxxxxx>]

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$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

begin:vcard
fn:Laurent Goubet
n:Goubet;Laurent
org:Obeo
email;internet:laurent.goubet@xxxxxxx
url:http://www.obeo.fr
version:2.1
end:vcard