Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mmt-dev] EmfUtil: content-type computation

Hi again,
-------- Original-Nachricht --------
> So content-types were made available. The platform/EMF arrange to use 
> the content type for reading files by analysing the file content.
As far as I understand org.eclipse.core.internal.content.ContentTypeCatalog
it is not only about analysing content thru IContentDescribers but as well about file name based content type matching and extension based matching.

> No consideration was given to creating files, since how can you create a 
> correct content telepathically.
Well it is not about telepathy :), but about providing means for the user to express his intentions, i.e. which content-type he wants to see/get.

> The onus was therefore on applications 
> to provide the missing control. This was not trivial so it's been 
> overlooked.
> Your question provoked consideration of the following three stage
> resolution
> a) identify the most restrictive output meta-model EPackage (easy 
> application functionality)
> b) convert the EPackage to its content-type (new EMF functionality)

IMHO, you can convert an EPackage to its content-types(!)

E.g. a metamodel for java bytecode might have the default xmi content-type, would quite naturally map to the java-classfile content-type and might as well have ResourceFactories for a jasmin-assembler-text-content-type and objectweb-asm-text-context-type.

Or consider a nifty DSL designed by a Graphiti guru to have an nice gui editor on top of its xmi representation while another text-centric dude implements based e.g. on EMFText a HUTN-like text-content-type and - just because he can - a java-like-text-content-type as well.

And while the user does not expect that the computer telepathically knows his content-type wishes, the user must have an opportunity to key-in his desired content-type, should he not? 

> c) create the resource by content type (already available)
> This approach just makes the contentTypeToFactory functionality work as 
> intended.
Actually I think it is already (mostly) working, but EMFUtil.createResource() needs some update.

The only problem with the existing framework is, that an IOException on
file non existence is not caught and preventing the file name and file extension lookup steps, again IMHO.



Uwe Ritzmann              Uwe.Ritzmann@xxxxxx

Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro!

Back to the top