4

I want to port a legacy data format, which consists of concepts similar to Eclipse Modeling Framework (EMF) Ecore: Elements with Parameters which have different datatypes and default values.

A custom-made tool lets you edit such model instances by a fancy table-based GUI.

Also, a common feature for the Parameters is that a Derivation Rule can be added which specifies that the Parameter value gets computed automatically from other parameters. That also seems similar to Ecore derived Attributes which could be implemented by Java Code or OCLinEcore.

However, the automatic derivation of a Parameter in the legacy format is optional. I.e. a user can always select such a derived parameter and select that he or she wants to enter the value manually. Hence, even derived Parameter values are not transient but always persisted, including the state whether the parameter is in "auto" or "manual" mode.

Is there any way in Ecore (including extensions like OCLinEcore) to persist derived attributes and to selectively/temporarily enable/disable derivation at runtime?

Workaround could be not to use Ecore's derived Attribute feature but to implement the optional derivation in the client code manually. However, the declaration of the optional derivation rule would be no Standard way. Any way to reuse OCLinEcore or alike?

Hauke
  • 134
  • 10

2 Answers2

4

Here is how do I do it in Xcore:

interface Identifier {
    id String uid
    boolean derive_enabled = "true"
    unsettable String uid_derived

    readonly String uid_generated get {  // this is the 'derived' parameter
        if (uid_derived == null || uid_derived.isEmpty) {
            uid_derived  = EcoreUtil.generateUUID().toString
        }
        if (derive_enabled) {
            uid = uid_derived
        }
        return uid
    }
}

You can easily implement it in Ecore/OCL-in-Ecore as well.

I persist the derived value of the parameter, but I can always change it manually (if I like) by changing the value of the boolean parameter. Then, I implement this interface for any class I need, so I have this feature globally.

Lii
  • 11,553
  • 8
  • 64
  • 88
vikin9
  • 497
  • 4
  • 16
  • Thanks for this approach. I'm not too familiar to Xcore: is it right that 'uid_generated' is the only transient attribute while 'uid' and 'uid_derived' will be both persisted? Is the reason that generateUUID will return different values for each call and thus you want to store a value once generated? So I guess when my values can be deterministically generated, I could omit the '_derived' persisted attribute. – Hauke Feb 25 '16 at 23:45
  • Yes, `uid_generated` is derived and can be treated as a function that is called every time you access an instance of this class. `uid` and `uid_derived` are just normal attributes of the class. Yes, `generateUUID()` function gives you new id every call, so you may omit one attribute out of `uid` `uid_derived`. Just install xcore (maybe you already have it in your Eclipse?) and try it! Converting xcore to ecore (and later to oclinecore) is very easy. – vikin9 Feb 26 '16 at 14:23
0

I'm not convinced that it is directly possible. The problem is that you have two possible values: manual and derived, which might be the same. If the derived is not persisted easy. But if the derived is persisted how do you know which is the master.

A similar problem arises in the the EMF Properties Views where it would be nice to distinguish with between a computed and an explicit value with a greyed/not-greyed background. e.g. is the GenModel Edit Plugin Id computed or explicit. Worse is a blank Property default-literal unset or explicitly blank.

Once you have an additional master-flag in your metamodel it should be relatively easy. Until then you may have a solution that works most times but other times can be confusing.

Ed Willink
  • 1,205
  • 7
  • 8