Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Sirius » RepresentationTemplate Use Case
RepresentationTemplate Use Case [message #1419588] Mon, 08 September 2014 21:08 Go to next message
Olivier Labrosse is currently offline Olivier LabrosseFriend
Messages: 49
Registered: November 2011
Member
Hi,

We were looking for a way to auto-generate a lot of RepresentationDescriptions based on templates, and it looks like the RepresentationTemplate EClass serves this purpose. What is unclear to us at this point is whether these templates can later be updated and re-generated, effectively allowing our application to migrate client DRepresentations. For example, we might some day decide to add more tools.

Could you give us an idea of the Sirius designs and/or features, current and future, that might help us achieve this goal of templating lots of representations while providing migration services on those templates?

Thank you!

-Olivier
Re: RepresentationTemplate Use Case [message #1421544 is a reply to message #1419588] Thu, 11 September 2014 14:01 Go to previous messageGo to next message
Pierre-Charles David is currently offline Pierre-Charles DavidFriend
Messages: 522
Registered: July 2009
Senior Member
Le 08/09/2014 23:08, Olivier Labrosse a écrit :
> Hi,

Hi.

> We were looking for a way to auto-generate a lot of
> RepresentationDescriptions based on templates

Can you give use an idea of why you need so many
RepresentationDescription? It may not be your case, but quite a lot a
variability can be encoded in a single RepresentationDescription using
existing Sirius mechanisms like conditional styles, computed colors,
style feature customization, representation extensions etc.

> and it looks like the RepresentationTemplate EClass serves this purpose.
> What is unclear to
> us at this point is whether these templates can later be updated and
> re-generated,

The existing support for templates is targeted to the VSM editor, where
it can help specifiers create complex representation descriptions from
higher-level descriptions.

You have to define your own high level "template configuration"
language/DSL, that the specifiers will edit from inside the VSM editor,
and the logic to transform these into raw Sirius VSM elements (that the
specifier would otherwise have to create by hand). The system makes sure
that when elements from the configuration part are edited, the
transformation is updated.

Note that this happens strictly at specification-time, as a help for the
specifier who creates/edits complex VSMs. The Sirius runtime does not
care how the .odesign it consumes were created.

I'm not sure this templating mechanism corresponds to your use case (at
least what I understand of it). If it does, be aware that this mechanism
has currently only been used to simplify the creation of Sequence
Diagram Descriptions, so we can't guarantee it is ready to handle
fully-general cases. If the way this works corresponds to your use case
but the current implementation is too limited for you in some way, do
not hesitate to contact us at Obeo to see what can be done.

> effectively allowing our application to migrate client
> DRepresentations. For example, we might some day decide to add more tools.

Sirius supports transparent and automatic updating of existing
DRepresentations when the corresponding RepresentationDescription
changes (this is actually what allows for live development of the VSMs.)

Concretely:
* you deploy a v1 of your modeler plug-ins (with v1 of your.odesign)
* users create representations (.aird files) using that version
* you deploy v2 of the same plug-ins, with udpated *.odesign definitions
* the first time users will open an old representation (created with v1)
with v2 of the VSM installed, it will be automatically refreshed
according to the new definition. New elements, style changes, new tools
etc. will be automatically available.

For this to work, the only thing you have to do is make sure the
identifiers of your VSM elements are stable across versions (same id for
the Viewpoint, RepresentationDescription, Layer, Mapping etc.).

> Could you give us an idea of the Sirius designs and/or features, current
> and future, that might help us achieve this goal of templating lots of
> representations while providing migration services on those templates?

The "templating lots of representations" and "providing migration
services" issues are orthogonal. The migration is automatic if you
follow the rules mentioned above. For the templating/variability there
are several levels:

1. Use mechanisms like conditional styles, style feature customizations,
representation extensions etc. if that is enough to capture the level of
variability you need.

2. Use the template mechanism to ease the creation of complex and/or
similar VSMs directly from inside the VSM editor.

3. The nuclear option: write some Java code taking whatever input
information you need and which generates conforming .odesign models
using the Sirius metamodel APIs. This can be integrated into the UI
using the normal Eclipse mechanisms, for example a wizard that can be
invoked by right-clicking on a VSM, which gathers some input from the
user and then programatically transforms the VSM or generates another
one. As long as the .odesign is valid, the Sirius runtime will not care
if it was created using the tree-based editor or some external program.

Hope this helps.

--
Pierre-Charles David - Obeo

Need professional services for Sirius?
http://www.obeodesigner.com/sirius


Pierre-Charles David - Obeo

Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
Re: RepresentationTemplate Use Case [message #1428964 is a reply to message #1421544] Mon, 22 September 2014 16:04 Go to previous message
Olivier Labrosse is currently offline Olivier LabrosseFriend
Messages: 49
Registered: November 2011
Member
We have a pretty big metamodel with over 100 distinct relationships. What we need is a CrossTableDescription for each start-end point pair, each taking the model root as the input in order to display all valid start points as rows and all valid end points as columns. Not only this, but we need mirror representations for when the user prefers rows to represent end points rather than start points.

We had already started working on the 3rd solution you described. I think we'll continue with that.

Thank you very much for all this insight, helps a lot with understanding the designs.

-Olivier
Previous Topic:Documentation / Tutorial
Next Topic:Optimize performances on big models
Goto Forum:
  


Current Time: Tue Mar 31 03:21:23 GMT 2020

Powered by FUDForum. Page generated in 0.02190 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top