Home » Eclipse Projects » Sirius » Dynamic creation of layers
|Dynamic creation of layers [message #1386785]
||Fri, 20 June 2014 12:56
| Daniel Strueber
Registered: April 2014
one of the greatest features in Sirius seems to be its support for multiple layers that can be switched on and off. This really has the potential to make life easier when working on big models.
However, as far as I recognize from the documentation, layers are always defined statically, that is, I need to know each desired layer at design time and include an entry for each layer in the .odesign model. Is this true, or is there maybe support for dynamic layers where I just create an arbitrary number of layers depending on a property outside the scope of the .odesign model?
[Updated on: Fri, 20 June 2014 12:57]
Report message to a moderator
|Re: Dynamic creation of layers [message #1386803 is a reply to message #1386785]
||Fri, 20 June 2014 15:28
|| Laurent Redor
Registered: July 2009
Indeed, the layers are defined statically in the VSM (.odesign file).
Le 20/06/2014 14:56, Daniel Strueber a écrit :
> one of the greatest features in Sirius seems to be its support for
> multiple layers that can be switched on and off. This really has to
> potential to make life easier when working on big models.
> However, as far as I recognize from the documentation, layers are always
> defined statically, i.e. I need to know each desired layer at design
> time and include an entry for each layer in the .odesign model. Is this
> true, or is there maybe support for dynamic layers where I just create
> an arbitrary number of layers depending on a property outside the scope
> of the .odesign model?
Laurent Redor - Obeo
Need training or professional services for Sirius?
|Re: Dynamic creation of layers [message #1387614 is a reply to message #1387147]
||Wed, 25 June 2014 10:28
|| Pierre-Charles David
Registered: July 2009
Le 24/06/2014 14:18, Daniel Strueber a écrit :
> One of the use-cases is a tool that allows to split a large model into
> sub-models . One component of the tool is a Sirius-based editor that
> is used to review an automatically generated splitting suggestion. In
> the viewpoint, we assign different colours and tags for each target
> sub-model. However, it would make life even easier if the user could
> hide/emphasize particular sub-models. We would need dynamic layers for
> that because the number of sub-models is not fixed.
> The other two use-cases are similar, except that they would benefit from
> dynamic layers even more: In scenarios where one element can have
> multiple assignments (or "tags", as accurately described by Felix),
> colors and labels quickly reach their limitations.
I understand the need, but I'm not sure layers are the right tool to
adress it (at least they were not designed with this in mind).
There may be other ways to achieve the result you want though. The
different parts you need seem to be:
1. A model, that you can populate dynamically, that identifies which
sub-models (or tags in Felix's example) are available, and which ones
are selected. You propose to reuse Sirius's notion of Layer for this,
but this could be another model. The "which sub-models are available"
part probably already exists in your domain model in a more or less
explicit way. The "which ones are selected" probably doesn't, but let's
assume for now it does.
2. You also need a UI to allow users to see these "categories", and
control which ones are selected. Your proposal is to reuse the "Layers"
combo in the tabbar, but it could be something else: a (dynamic) context
menu created in Java using the standard Eclipse contribution mechanisms,
or even another combo integrated into the diagram's integrated tab-bar
(if you are running on Luna, the tab-bar can be extended with your own
actions using standard Eclipse mechanisms).
3. Finally, you need a way to control the visibility and/or styling of
your diagram elements depending on which categories the user has
enabled. To completely hide elements which are not part of a selected
category, you can use a Mapping Filter  with a condition which
depends on the current selection of categories. To alter the visual
style of elements instead of completly hiding them, you can use
Conditional Styles , once again with a condition on the current
selection of categories.
I mentioned earlier that "which categories are selected" is probably not
an information you have in your domain model. Depending on your case it
could make sense to store it there, but if not, there is a mechanism in
Sirius (called "feature extensions") which allows you to store custom
data inside the aird files, so that you can access them in the
definition of your representations, but they do not "pollute" your
domain model. This mechanism is not documented right now, but if you
decide to go this way we can provide some pointers, and maybe take this
opportunity to write the missing doc.
Hope this helps. Don't hesitate if you have further questions.
|Re: Dynamic creation of layers [message #1391043 is a reply to message #1388298]
||Mon, 30 June 2014 11:11
|| Pierre-Charles David
Registered: July 2009
Le 26/06/2014 10:25, Daniel Strueber a écrit :|
> Thanks a lot, Pierre. In the light of your proposed solutions, I now
> agree that dynamic layers are indeed not necessary to handle our
> use-cases. The feature extension mechanism surely sounds relevant for
> us. Documentation would be brillant, but a usage example may also help.
You can find an example in the project at . The example still refers
to the old pre-Sirius fr.obeo.dsl.viewpoint namespace, but except for
the package names this API has not changed in Sirius.
Basically you need the following things:
1. A (generally small) metamodel which defines the custom data you want
to put into the aird file. You must have a "root type" which extends
DFeatureExtension from the Sirius metamodel. See .
2. A Java class which implements the FeatureExtension interface from the
Sirius API and one which implements FeatureExtensionServices. In basic
cases they can be pretty trivial. See .
3. The extension must be registered through the appropriate extension
point, see .
4. Once this is done, you can use the FeatureExtensionsManager API to
retrieve (or create) the instance of your data model associated to a
given Sirius session (represented by a DAnalysis in the code). You can
then query and manipulate it however you want. See  for an exemple of
Java methods to help with the lifecycle.
Going back to your case, you would then write filtering and/or
conditional style expressions which invoke Java code (for example as
"service:" calls ) to test the current state of your custom "which
categories are selected" model.
> By the way, congratulations for releasing Sirius 1.0.0!
Current Time: Sun Jul 23 23:07:36 GMT 2017
Powered by FUDForum
. Page generated in 0.03106 seconds