Home » Modeling » EMF » Partial model saves to be used as templates
|
| Re: Partial model saves to be used as templates [message #1090636 is a reply to message #1090613] |
Tue, 20 August 2013 12:31   |
|
Hi, Mauro,
See some comments in-line, below.
HTH,
Christian
On 2013-08-20 11:58:53 +0000, Mauro Candarelli said:
> Hi,
> my model instances are highly repetitive, so it would be beneficial for
> the user to have "canned templates" to insert in certain positions.
> I would like to be able to save a (series of) complete sub-trees of the
> model as pre-built "templates" and successively reload them (instead of
> just creating the root).
I think this has been done before. Applications such as Papyrus
provide "model templates" for initialization of new projects and
resources. There may be ideas to be gleaned from such.
> I plan to do this using EcoreUtil.copy to get a sub-tree and put the
> result in a resource to be saved in the usual way (XMI).
> The reverse could be done in a similar way, loading a separate sub-tree
> and than grafting it to the real model.
This sounds quite reasonable; it's a solid use case for the Copier.
> Two questions:
> 1) is this the "Right Way" or is there a "Better Way"?
EMF is so flexible that there are often several "right ways." :-)
You may not have to bother with the copy step if your resources don't
use UUIDs for references, because the same IDs can safely be repeated
in all of the objects from the template in each model created from it.
It may be sufficient just to load the template resource and move its
contents into the appropriate place in the model's tree. If the same
template can be applied repeatedly in a model, then I would expect the
EMF resource to assign new IDs to second and subsequent occurences of
the "same" objects.
If your resources don't use IDs (it seems they don't) then this isn't a
concern; you can just move the objects from the template each time.
> 2) I have a series of "global" values in my model, contained in model
> root and referenced everywhere; I expect the usual serialization
> mechanism ("@Xxx.##" notation) to be rather brittle and collapse if
> something changes in the "global" lists between template-save and
> template-usage. Is there some way to overcome the problem? (e.g.: some
> cross-checking I can do).
Do you mean that the objects in a template can reference these shared
objects, such that multiple applications of the template must reference
the same objects that already exist in the model? That complicates the
logic of "applying" the template, and I'm not sure that using IDs in
the resource would make it easier. One reason for using IDs (for
example, generated UUIDs) is to establish stable object identities for
references, that don't depend on an object's location in the tree.
>
> TiA
|
|
|
| Re: Partial model saves to be used as templates [message #1090660 is a reply to message #1090636] |
Tue, 20 August 2013 13:15 |
 Mauro Condarelli
Messages: 428
Registered: September 2009 |
Senior Member |
|
|
Thanks Christian,
comments inline.
On 20/08/2013 14:31, Christian W. Damus wrote:
> Hi, Mauro,
>
> See some comments in-line, below.
>
> HTH,
>
> Christian
>
>
> On 2013-08-20 11:58:53 +0000, Mauro Candarelli said:
>
>> Hi,
>> my model instances are highly repetitive, so it would be beneficial for the user to have "canned templates" to insert in certain positions.
>> I would like to be able to save a (series of) complete sub-trees of the model as pre-built "templates" and successively reload them (instead of just creating the root).
>
> I think this has been done before. Applications such as Papyrus provide "model templates" for initialization of new projects and resources. There may be ideas to be gleaned from such.
I'll have a look.
If You have pointers... ;)
>
>
>> I plan to do this using EcoreUtil.copy to get a sub-tree and put the result in a resource to be saved in the usual way (XMI).
>> The reverse could be done in a similar way, loading a separate sub-tree and than grafting it to the real model.
>
> This sounds quite reasonable; it's a solid use case for the Copier.
Ok, I can proceed.
>
>> Two questions:
>> 1) is this the "Right Way" or is there a "Better Way"?
>
> EMF is so flexible that there are often several "right ways." :-)
It' enough to avoid "Wrong Ways" (lots of them lying around!)
>
> You may not have to bother with the copy step if your resources don't use UUIDs for references, because the same IDs can safely be repeated in all of the objects from the template in each model created from it. It may be sufficient just to load the template resource and move its contents into the appropriate place in the model's tree. If the same template can be applied repeatedly in a model, then I would expect the EMF resource to assign new IDs to second and subsequent occurences of the "same" objects.
>
> If your resources don't use IDs (it seems they don't) then this isn't a concern; you can just move the objects from the template each time.
I don't (currently) use UUIDs (never used, actually).
I'm not sure I won't be forced to use them, though (see below).
>
>
>> 2) I have a series of "global" values in my model, contained in model root and referenced everywhere; I expect the usual serialization mechanism ("@Xxx.##" notation) to be rather brittle and collapse if something changes in the "global" lists between template-save and template-usage. Is there some way to overcome the problem? (e.g.: some cross-checking I can do).
>
> Do you mean that the objects in a template can reference these shared objects, such that multiple applications of the template must reference the same objects that already exist in the model? That complicates the logic of "applying" the template, and I'm not sure that using IDs in the resource would make it easier. One reason for using IDs (for example, generated UUIDs) is to establish stable object identities for references, that don't depend on an object's location in the tree.
I mean I have several kind of objects that are "orthogonal" to real model objects and I put (in lack of a better place) in model root.
There are three different kinds of such objects:
1) strings for internationalization purposes (Yes, they are in the model; no, I don't think it's a good idea... don't ask!)
2) enumeration-like values used in various model classes (these cannot be real enums because they may vary over time; in theory they should be some kind of "static Lists" attached to EClasses, with references in the EClass instances, but EMF do not support such a beast, so I have real containment ELists attached to the root and references pointing to them).
3) real shared objects akin to "global variables" where model objects (i.e.: runtime using the model) will take values needed for some computation or will deposit results.
In all cases the lists can change (*usually* by adding new elements, but removal is still possible!), usually "slowly".
It would be important to be able to reconnect grafted templates to the right "global" objects; for this I fear UUIDs are the right way to go. I could "invalidate" entries in "global" lists and keep adding, but that is rather inelegant and would preclude using enhanced techniques like object reordering t improve search speed.
Can You advise, please?
TiA
|
|
|
| Re: Partial model saves to be used as templates [message #1091401 is a reply to message #1090660] |
Wed, 21 August 2013 13:00 |
|
Hi, Mauro,
See some follow-up in-line.
HTH,
Christian
On 2013-08-20 13:15:00 +0000, Mauro Candarelli said:
> Thanks Christian,
> comments inline.
>
> On 20/08/2013 14:31, Christian W. Damus wrote:
>> Hi, Mauro,
>>
>> See some comments in-line, below.
>>
>> HTH,
>>
>> Christian
>>
>>
>> On 2013-08-20 11:58:53 +0000, Mauro Candarelli said:
>>
>>> Hi,
>>> my model instances are highly repetitive, so it would be beneficial for
>>> the user to have "canned templates" to insert in certain positions.
>>> I would like to be able to save a (series of) complete sub-trees of the
>>> model as pre-built "templates" and successively reload them (instead of
>>> just creating the root).
>>
>> I think this has been done before. Applications such as Papyrus
>> provide "model templates" for initialization of new projects and
>> resources. There may be ideas to be gleaned from such.
> I'll have a look.
> If You have pointers... ;)
Open the New Papyrus Model wizard and activate the plug-in spy. :-)
-------- 8< --------
>>> 2) I have a series of "global" values in my model, contained in model
>>> root and referenced everywhere; I expect the usual serialization
>>> mechanism ("@Xxx.##" notation) to be rather brittle and collapse if
>>> something changes in the "global" lists between template-save and
>>> template-usage. Is there some way to overcome the problem? (e.g.: some
>>> cross-checking I can do).
>>
>> Do you mean that the objects in a template can reference these shared
>> objects, such that multiple applications of the template must reference
>> the same objects that already exist in the model? That complicates the
>> logic of "applying" the template, and I'm not sure that using IDs in
>> the resource would make it easier. One reason for using IDs (for
>> example, generated UUIDs) is to establish stable object identities for
>> references, that don't depend on an object's location in the tree.
> I mean I have several kind of objects that are "orthogonal" to real
> model objects and I put (in lack of a better place) in model root.
>
> There are three different kinds of such objects:
> 1) strings for internationalization purposes (Yes, they are in the
> model; no, I don't think it's a good idea... don't ask!)
Then I won't! :-) I understand that the world presents us with
practical necessities.
> 2) enumeration-like values used in various model classes (these cannot
> be real enums because they may vary over time; in theory they should be
> some kind of "static Lists" attached to EClasses, with references in
> the EClass instances, but EMF do not support such a beast, so I have
> real containment ELists attached to the root and references pointing to
> them).
I remember following this discussion in the newsgroup. These objects
seems like they could have intrinsic IDs that the resource might use
(an "isID" EAttribute). Does everything else in your model also
possibly have intrinsic IDs? I have little experience of using them,
myself. I don't even know whether a Resource can use intrinsic IDs for
the URI fragments of some objects like these that need stable
references and path-style URI fragments for other objects, but I
wouldn't be surprised if it worked. You might try it.
> 3) real shared objects akin to "global variables" where model objects
> (i.e.: runtime using the model) will take values needed for some
> computation or will deposit results.
I remember this discussion, too.
> In all cases the lists can change (*usually* by adding new elements,
> but removal is still possible!), usually "slowly".
> It would be important to be able to reconnect grafted templates to the
> right "global" objects; for this I fear UUIDs are the right way to go.
> I could "invalidate" entries in "global" lists and keep adding, but
> that is rather inelegant and would preclude using enhanced techniques
> like object reordering t improve search speed.
Yes, the framework should not require such constraints on the lifecycle
of model elements. Schema/metadata elements, perhaps.
> Can You advise, please?
Most of the EMF-based models that I have used in my daily work over the
last 10 years have used UUIDs without serious problems. Most
applications don't assume that these IDs are actually unique across all
resources (many applications copy resources with all of the IDs intact;
even the UML2 project's UML Metamodel publishes each successive release
with same IDs based on metaclass names even though the resource
interprets them as UUIDs).
What reasons do you hae for resisting UUIDs (or other forms of
extrinsic ID)? That's the best suggestion I have from my limited
experience of EMF object identification issues.
|
|
| |
| Re: Partial model saves to be used as templates [message #1092165 is a reply to message #1091505] |
Thu, 22 August 2013 12:06 |
|
On 2013-08-21 15:53:00 +0000, Mauro Candarelli said:
> On 21/08/2013 15:00, Christian W. Damus wrote:
>> What reasons do you hae for resisting UUIDs (or other forms of
>> extrinsic ID)? That's the best suggestion I have from my limited
>> experience of EMF object identification issues.
>
> No reason, actually.
> I simply never used them before, so I wanted to be sure it's the way to
> go before I plunge and start learning about them.
>
> Any pointer to relevant examples welcome.
org.eclipse.uml2.uml.internal.resource.UMLResourceImpl
It overrides useIDAttributes() to return false and useUUIDs() to return true.
cW
>
> Thanks a lot.
> Mauro
|
|
|
| Re: Partial model saves to be used as templates [message #1096514 is a reply to message #1091505] |
Wed, 28 August 2013 13:36 |
|
Hi, Mauro,
You might be interested in Ed's performance considerations in the
recent "Performance of Intrinsic vs Extrinsic ID" thread in this forum.
I haven't used the eKeys capability myself much, so I had forgotten
about it, but he's right (of course): it can help to provide URI
fragments that are stable at least with respect to reordering of
elements in containment features, though I think not if objects are
commonly moved into different containers.
cW
On 2013-08-21 15:53:00 +0000, Mauro Candarelli said:
> On 21/08/2013 15:00, Christian W. Damus wrote:
>> What reasons do you hae for resisting UUIDs (or other forms of
>> extrinsic ID)? That's the best suggestion I have from my limited
>> experience of EMF object identification issues.
>
> No reason, actually.
> I simply never used them before, so I wanted to be sure it's the way to
> go before I plunge and start learning about them.
>
> Any pointer to relevant examples welcome.
>
> Thanks a lot.
> Mauro
|
|
|
Goto Forum:
Current Time: Fri Apr 26 05:45:16 GMT 2024
Powered by FUDForum. Page generated in 0.03823 seconds |
] 
Search
Help
Register
Login
Home
