[acceleo-dev] Dynamic polyphormism + overriding for templates and querie

[pere lengo <perelengo@xxxxxxxxxxx>]

Good Evening,

I am writing because, some time ago I funded a MDA company, that vastly implemented Acceleo as a code generation mechanism.

As part of the architecture of the framework  a crucial part of the requirements of the framework required dynamic overriding and polyphormism, in order to allow (for example) setting different name rules for various companies as per their naming standards requirements.

One of the major problems found is that the overriding mechanism is not suitable for generators that are not open-sourced because it is mandatory to import the extended template and use it explicitly, which makes extension mechanism very limited. A similar problem applies to queries, that cannot be overriden.

Another very interesting extension mechanism that requires implicit import declaration is Polyphormism. However, the fact that it requires an implicit import also makes it less usable.

As an example of what I attempted to achieve:

-I have a _javascript_ generator that generates a _javascript_ function that has to invoke a remote server.

-The client code could be generated for REST protocol, JSON-RPC protocol, or whatever protocol the architect decides, depending on the UML stereotypes applied to ports connecting the client and server component.

-I want to be able to generate the client for more than these two protocols without having to import the new generators in the old templates.

To solve all of these problems, I've patched a couple of classes, to allow dynamic polyphormism without imports and query dynamic overriding mechanisms.

For example, we want to make a call to a template as follows:

[generateClientInstanceByTecnology(sourceTecnology,targetTecnology, targetInterface, sourcePorts, sourceComponent, targetPorts, targetComponent, model)/]

Which invokes:

[template public generateClientInstanceByTecnology (sourceTecnology : Stereotype, targetTecnology : Stereotype,  targetInterface : Interface , sourcePorts : Set(Port), sourceComponent : Component, targetPorts : Set(Port), targetComponent : Component,  model : Model) ]

[ generateClientInstanceByTecnology2(sourceTecnology.getStereotypeMetaClass(), targetTecnology.getStereotypeMetaClass(), targetInterface, sourcePorts, sourceComponent, targetPorts, targetComponent, model)/]

[/template]

And the default implementation:

[template public generateClientInstanceByTecnology2 (sourceTecnology : OclAny, targetTecnology : OclAny,  targetInterface : Interface , sourcePorts : Set(Port), sourceComponent : Component, targetPorts : Set(Port), targetComponent : Component,  model : Model)  ]

// FIXME - Non available generators for

// [sourceTecnology/]

// and

// [targetTecnology/]

[/template]

An implementor can extend this generator for example for Dojo (_javascript_ framework) clients, requesting HTTP servers in this way:

[template public generateClientInstanceByTecnology2 (sourceTecnology : Dojotoolkit , targetTecnology : Http, targetInterface : Interface , sourcePorts : Set(Port), sourceComponent : Component, targetPorts : Set(Port), targetComponent : Component,  model : Model) ]

....

[/template]

Another implementor can extend this generator for example for Angular (_javascript_ framework) clients, requesting JSON-RPC servers in this way:

[template public generateClientInstanceByTecnology2 (sourceTecnology : Angular, targetTecnology : JsonRpc, targetInterface : Interface , sourcePorts : Set(Port), sourceComponent : Component, targetPorts : Set(Port), targetComponent : Component,  model : Model) ]

....

[/template]

I would like to know what the requirements to push the code to the repository are and how to document these functionalities.

I have this patch applied to R3_3_maintenance branch- do you think that it is necessary to upgrade it to the master version and make appropiate tests to validate it? If so, I kindly request your assitance for the pulling phase.

Many thanks,

Pere Joseph Rodríguez