Refer to an accessory model from inside an editor aspect

Avatar
Permanently deleted user
Created

Hi,

I have created some concept instances inside an accessory model, which are basically predefined constants for the language users. I can use them properly from inside the sandbox.

However a cannot refer to them from inside the editor aspect, not even after I added the accessory model to the editor aspect as dependency. I would like to show the different constants differently to the user (besides their different names), so e.g. one of the constants would be red, the other one would be green, etc.

So, is there any way to refer to an accessory model from inside an editor aspect? (My feeling is that it is not possible due to some bootstrap problems.)

A workaround for this could be that I would define an enum, and each concept instance would refer to a different enum member, and I would use the enum value of the concept instances inside the editor.

Thanks,

David

 

Votes

2

Share

2 comments
Avatar
Permanently deleted user
Created

I think I found a proper solution. I think I had probably misused the accessory models before, but it would be good if someone more experienced could confirm.

Accessory model + smart references

This is the solution I used, but it has some problems. A simplified version of it looks like this:

concept Transition extends BaseConcept
                   implements <none>

children:
  targetReference : TransitionTarget[1]

references:
  << ... >>
abstract concept TransitionTarget extends BaseConcept
                                  implements <none>
concept TransitionTargetStateReference extends TransitionTarget
                                       implements <none>

children:
  << ... >>

references:
  state: State[1]
concept State extends BaseConcept
              implements INamedConcept
concept TransitionTargetConstantReference extends TransitionTarget
                                          implements <none>

children:
 << ... >>

references:
  targetConstant: TransitionTargetConstant[1]
final concept TransitionTargetConstant extends BaseConcept
                                       implements INamedConcept

instance can be root: true

And the instances in the accessory model are the followings:

TransitionTargetConstant final-state
TransitionTargetConstant fail-state

What I like in this solution is that there exists exactly one instance of final-state, and exactly one instance of fail-state.

However, while the users of the language can use these instances easily (in their models they can refer to the instances, intellisense works, etc.), I cannot refer to these instances from the editor aspect, and I guess, I cannot refer to them from the generator aspect either (I did not try it yet).

Moreover, this way the users of the language could also create instances of TransitionTargetConstant, which would not make any sense in my language.

To properly identify these instances inside my editor aspect, I would need to "mirror" the TransitionTargetConstant instances by creating and enum, but this would be very clumsy, and I would still not solve the problem of creating references to these instances from code (e.g. from inside an intention):

enumeration datatype TransitionTargetType
  value 1  presentation FinalState
  value 2  presentation FailState
final concept TransitionTargetConstant extends BaseConcept
                                       implements INamedConcept

instance can be root: true

properties:
  transitionTargetType : TransitionTargetType

Accessory model + normal references

This is similar to the previous solution (and still has the same problems), but it uses normal references instead of smart references:

concept Transition extends BaseConcept
                   implements <none>

children:
  << ... >>

references:
  targetReference : ITransitionTarget[1]
interface concept ITransitionTarget extends <none>
concept State extends BaseConcept
              implements INamedConcept, ITransitionTarget
final concept TransitionTargetConstant extends BaseConcept
                                       implements ITransitionTarget

instance can be root: true

And the instances in the accessory model are the followings:

TransitionTargetConstant final-state
TransitionTargetConstant fail-state

The language is simpler; however, the same problems persist.

Furthermore, using normal references like this instead of using smart references has the disadvantage that now we pollutes the definition of the State concept with the knowledge that it can be an ITransitionTarget.

Concepts + smart references

This is the solution that seems to be quite right, and works as well:

concept Transition extends BaseConcept
                   implements <none>

children:
  targetReference : TransitionTarget[1]

references:
  << ... >>
abstract concept TransitionTarget extends BaseConcept
                                  implements <none>
concept TransitionTargetStateReference extends TransitionTarget
                                       implements <none>

children:
  << ... >>

references:
  state: State[1]
concept State extends BaseConcept
              implements INamedConcept
final concept FinalState extends TransitionTarget
                         implements  <none>

instance can be root: false
final concept FailState extends TransitionTarget
                        implements  <none>

instance can be root: false

What I do not like in this solution is that there exist more instances of final-state, and more instances of fail-state.

However, the users of the language can use final-state and fail-state easily (in their models they can refer to them, intellisense works, etc.), and I can refer to final-state and fail-state from the editor aspect, and from the generator aspect too.

So, this seems to be a quite proper solution, but someone more experienced could confirm.

 

Thanks,

David

 

0
Avatar
Permanently deleted user
Created

Could anybody confirm whether my solution is right or wrong?

 

Thanks,

David

0

Please sign in to leave a comment.