Provide a simple Aspect that has business meaning, like an Aspect for configuring Logging level on an Action.

Provide a simple Aspect that has business meaning, like an Aspect for configuring Logging level on an Action.

−

Available in the CVS under org.eclipse.jwt/we/jwt-we-plugins in the jwt-we-sample-logging and jwt-we-sample-logging.edit projects.

+

Available in the CVS under [[http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jwt/we/jwt-we-plugins/?root=Technology_Project|org.eclipse.jwt/we/jwt-we-plugins]] in the jwt-we-sample-logging and jwt-we-sample-logging.edit projects.

Features

Features

Line 152:

Line 152:

See samples mentioned within each previous paragraph.

See samples mentioned within each previous paragraph.

−

Summarizing them all, available in the CVS under org.eclipse.jwt/we/jwt-we-plugins :

+

Summarizing them all, available in the CVS under [[http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jwt/we/jwt-we-plugins/?root=Technology_Project|org.eclipse.jwt/we/jwt-we-plugins]] :

* Standalone Dynamic Aspect sample

* Standalone Dynamic Aspect sample

* Registered Dynamic Aspect sample

* Registered Dynamic Aspect sample

* Static Aspect sample

* Static Aspect sample

* Child Extenders Aspect sample : shows how to combine Aspects with EMF Child Extenders (which could also be used on their own).

* Child Extenders Aspect sample : shows how to combine Aspects with EMF Child Extenders (which could also be used on their own).

What are aspect model extensions for

JWT provides a mechanism allowing to store typed custom information in workflow models, thanks to an additional *_conf file (actually, it works for any kind of EMF model). Profiles describe what kind of additional information (or Aspects) can be stored on model elements. Such profiles and aspects can be provided by JWT integrators to let their users provide complex information needed by their custom features, or designed by end users to let them add information as simple as key-value properties.

Using aspect model extensions

Installation

Aspect model extensions should be available by default in your JWT installation starting from 0.6 (upcoming).

If they are not, here are the additional JWT eclipse plugins you need in your JWT installation (or workspace) :

jwt-we obviously as well as jwt-we-conf.we, which contains aspect integration in jwt-we

Example : open this TODO metamodel, it should show custom information.

Enabling model extensions

To enable its custom Conf in your (workflow) model : if it is not already enabled for your xxx.workflow model, i.e. if it has no custom Conf already (xxx.workflow_conf file),

start from a vanilla (workflow) model xxx.workflow and open it.

open the ManageProfiles UI. One way is to select the corresponding editor sheet, or open it if it is not already by right click > Editor sheets > Manage Profiles. Another way could be : right click and select ExternalActions > ManageProfiles, which opens the ManageProfiles dialog.

Since there is no conf yet, the ManageProfiles UI is empty and only permits to activate profiles by clicking on a button

click on this button, which creates a related, empty conf file, named xxx.workflow_conf .

Creating custom aspect model extensions

Setting up simple (key-value) additional model extensions

This can be done (without code nor EMF design) thanks to the jwt-we-conf-property official JWT metamodel extension.

1. Create your own custom profile (if you don't have one already) :

double-click on a base (workflow) model related *_conf file (or a standalone .conf file created with the Conf Wizard) to open it in the Conf Editor

create your own custom Profile in it, ex. by right-click > New Child> Profile on the ConfModel root element. Give it a distinct name and URL.

2. Design a new Property aspect in it :

create one (or more) aspect(s) on your Profile using right click on it > New Child > New Aspect

then right-click on the editor, choose "Load Resource..." > "Browse Registered Plugins..." and select "org.eclipse.jwt.conf.property", so you can select jwt.we.conf.property.Property as its Aspect Instance Type,

also give it a unique id, and select which target model element type(s) it will be available on

3. When they are ok, install your extension :

if you were working on a (workflow) model related *_conf file, export it to a standalone .conf file. To do so, select the ManageProfile tab of the (workflow) model editor, and in the "Export profiles that are not among installed ones", choose a new target .conf file and click on the "Export" button.

put your standalone .conf file in the "conf" autodiscovery directory of your JWT installation, or register in a plugin with the "org.eclipse.jwt.we.conf.model.conf" extension.

If you put it to true, you can now put the (workflow) model's related ConfModel's "useEmbeddedConf" property to false again, since your new profile is available among the installed ones.

You can now use your custom designed model extensions in (workflow) models as shown previously.

NB. as said, property information and configuration are stored in the *_conf file, which must be provided along with your (workflow) model file

Example : see jwt-we-conf-property-model/samples .

Additional features

On your self-designed aspect, you can

disable "autocreated" (so it will not be automatically created on any newly created node but will have to be created explicitly),

enable "multiple" (so more than one can be created)

or give it a default value (works only with primitive types for now)

To test it while designing it :

put the (workflow) model file in profile design mode, by putting the "Use Embedded Conf" property to "true" in or the PropertySheet on the ConfModel, or using the Manage Profiles tab of the (workflow) model editor

NB. Also called "embeddedConf" mode, it allows the (workflow) model to directly use profiles available in its _conf file, and not only Profiles that are provided by the JWT installation. But you can also directly edit a .conf file, then install it and test it from a regular (workflow) model file.

you can now add aspects on your (workflow) model element by right-clicking on it, selecting "New Child..." and from there the aspect of your choice. This works in the Conf Editor as welle as in the (workflow) model editor.

Others

FAQ : if your _conf file is broken (i.e. contains bad XML or EMF, or refers to unknown EMF packages), it can't be opened by the Conf Editor and only the "Enable profiles" button is avalable in the ManageProfile tab. To solve it, open it with the text editor instead, then either open it again with the Conf Editor and do right-click > Reload Conf Model, or open the ManageProfile tab and click on "Enable profiles".

This can be done by designing and using "dynamic EMF" aspects, i.e. with EMF design but without code :
1. design an EMF type extending jwt.we.conf.AspectInstance :

create a new EMF model file near your (workflow) model file by using the Eclipse New Ecore EMF model wizard

in it, name its package as you want and create there a new EMF type

in the sample EMF editor, right-click on it, choose "Load Resource..." and select among plugin (devtime) resources jwt-we-conf-model's the ConfMetaModel.ecore , so you can let your new type extend jwt.we.conf.AspectInstance using the Extend Type dialog

design your custom model extension : add EMF attributes and references on your type, create other types or load them from other resources and refer to it...

2. then set it up in a custom Profile :

as above for setting up custom "dynamic" Properties, open a (workflow) model-related *_conf or a standalone *.conf file with the Conf Editor, and in a custom Profile create a new Aspect

in the Conf Editor, right-click on it, choose "Load Resource..." and select among file resources your custom metamodel, so you can let your aspect's instance type by the custom EMF type you've just designed

NB. you must provide your custom EMF metamodel file (and possible additional loaded file models), along with the _conf file in the same directory as your workflow models.

EMF model extension alternatives

If you're developing an EMF-based tool, there are three ways to add custom information to an EMF model :

extend an existing type of the model with your own type. This is only interesting to create well identified subtypes, i.e. that could have been provided in the base model beforehand. If it is the case, please consider contributing it to JWT's core metamodel. See an example in jwt-we-plugins/jwt-we-sample-aspectchildextenders .

add instances of your own type to an openly typed reference (Any, EObject...). This is a good all-around solution but requires that such a reference exists in the model, and doesn't provide management of information coming from different third-party providers. Therefore we didn't do so in JWT.

manage instances of your own types in another model that let them refer to the main model's elements. This non-intrusive solution works with any model without prerequisite and allows to share type extensions between model types. In JWT, Aspects do this in a simple, typed way that allows for having custom-information coming from different third-party providers, while the genmodel file is a more complex example.

Allowing aspects (jwt-we-conf*) in your EMF model

put the aspects (jwt-we-conf*) plugins in your plugin Feature

let your model plugin depend from jwt-we-conf and the base classes of your EMF.edit's ItemProviders extend AspectsEnrichedBaseItemProvider rather than BaseItemProvider. This enables right-click > New Child > aspectxxx commands, as well as aspect behaviours (mainly autocreated aspects). Alternatively, you can write its code in your root generated class.

that's it ! If you want, you can now also develop a custom Property Sheet tab for your aspect, or a view, an editor sheet...

Aspect model extension samples

Logging Aspect sample

Provide a simple Aspect that has business meaning, like an Aspect for configuring Logging level on an Action.

Available in the CVS under [[1]] in the jwt-we-sample-logging and jwt-we-sample-logging.edit projects.

Features

a property typed by a predefined enumeration (for logging) such as "WARN", "SEVERE", "INFO". This translates to a listbox in the property sheet UI.

a dedicated "Logging" property tab in the property sheet

an installed conf comprising of a single aspect definition allowing Logging aspect instances to decorate Actions

sample workflows with Logging conf and instance decorations on Actions.