|
| Re: RepresentationTemplate Use Case [message #1421544 is a reply to message #1419588] |
Thu, 11 September 2014 14:01   |
|
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
|
|
|
|
Powered by
FUDForum. Page generated in 0.02571 seconds
] 
Search
Help
Register
Login
Home
