|
|
|
Re: Adding classes to generated Package [message #903979 is a reply to message #903967] |
Mon, 27 August 2012 13:38 |
Ed Merks Messages: 33218 Registered: July 2009 |
Senior Member |
|
|
Dominik,
Comments below.
On 27/08/2012 3:14 PM, Dominik Muttenthaler wrote:
> Thanks for the fast answer(s),
>
>> It's generally a bad idea for the constructor to populate features...
> What i do is the following:
> id = eClass().getName() + EcoreUtil.generateUUID();
>
> I already see that this isn't good, as soon as i have a dynamic class
> with supertype Resource since EMF creates the Resource Class and then
> sets the eClass Property.
> Where else would u suggest to do this?
Presumably your derived class extends Resource and then the ResourceImpl
is still constructed. The problem is that when you deserialize or copy
some instance, you needlessly create IDs...
Probably better is to compute and cache the ID in the getter. That way
there's an ID there is anything asks for it, but until then, there isn't
one and when you deserialize, the value from the serialization will be set.
>
>
>> That sounds complex for the user to manage. Probably better is that
>> you provide some type of mechanism whereby the user can annotate
>> resources with additional properties (much like EModelElement can be
>> annotated).
> My users are software-developers, and they would like to edit a
> ecore-file.
:-P
>
>
>> You can't modify a generated package at all. You can create new
>> dynamic packages and use those. ReflectiveItemProviderAdapter shows
>> how such newly discovered packages can contribute to the child
>> creation menu.
> Manged to do that already
> Is it possible that classes created out of the dynamic package have
> the same xmlns as classes created out of the genereated package?
No, each package must have a unique nsURI.
> ATM i have 2 xmlns that correspond to the URIs of the Resources
>
>
>> You can only do that if your base package itself is dynamic. Is that
>> the case?
> Not sure where to set that. But the base package is generated code so
> i guess its not.
Yes, that should have been obvious to me given you talked about
specializing the constructor.
So you need to create new packages with new classes.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
|
Re: Adding classes to generated Package [message #904896 is a reply to message #904844] |
Wed, 29 August 2012 10:42 |
Dominik Muttenthaler Messages: 5 Registered: August 2012 |
Junior Member |
|
|
> Are you using ReflectiveItemProviderAdapter? It sounds like an issue of
> having populated the cache of allEClasses. A brute for approach would
> be to call IEditingDomainItemProvider.getNewChildDescriptors for each
> EObject in the tree (or at least once for each EObject with a different
> eClass()).
Thank you very much.
It looks like the "magic" happens in ReflectiveItemProvider.gatherMetaData.
Since its going up to the package and adds all Classes of that Package i thinks its enough to call IEditingDomainItemProvider.getNewChildDescriptors for one EObject (doesn't matter witch) in EPackage.
[Updated on: Wed, 29 August 2012 10:58] Report message to a moderator
|
|
|
Powered by
FUDForum. Page generated in 0.04153 seconds