[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mmt-dev] EmfUtil: content-type computation
|
Hi
I think you misunderstand my comments.
I cannot see where you are disagreeing with me.
I do not now understand what you really want.
If you want to continue this discussion, please start again and express
your self clearly.
Regards
Ed Willink
On 18/06/2012 23:05, Uwe Ritzmann wrote:
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.
Regards
Uwe
