Community
Participate
Working Groups
In the actions sequence of a tool, it should be possible to add an action which calls a service. Currently, one must use the "Change context" action.
If required this new ModelOperation should only be able to evaluate an interpreted expression (service:, [../], feature:,..) without expecting to change the evaluation context. To me it should not be able to contain any other ModelOperation. Then if someone wants to evaluate some expression and get its result as new context and then call other moel operations on it, the ChangeContext will continue to be the operation to use. But I am not sure this changes is really required as the existing ChangeContext operation already cover the possibility to call a service ie the evaluation of an interpreted expression. Note that the ExternalJavaAction operation allows to call some java code too (but it requires to provide the correpsonding extension in the plugin.xml of the modeler plugin). You demand might only indicate that we should rename the Change Context operation and improve the documentation to better indicate its possibilities.
Hi Frederic do you talk specifically about java service call, i.e. "service:" or all callable service in general, java and Acceleo3?
From what I understand, what you want is an operation to execute a statement (in the sense of http://en.wikipedia.org/wiki/Statement_%28computer_science%29): evaluate an arbitrary intepreted expression for its side-effects, but ignore any value the expression may produce/return. This may be needed, but with this, bug #443698 and probably others, it is more and more clear that we are re-inventing, badly and incrementaly an actual imperative programming language. With all the problems of doing this piecewise: no proper scoping rules for variables, no distinction between language constructs and primitives, no mechanism for code reuse, no mechanism for error reporting and handling (see the ugly workaround of calling to a Java service which throws an exception to abort the execution of a tool), inconsistencies between operations which look similar, (almost) no extensibility, etc. IMO, we should either: 1. Accept that we need theses "model operations" to be a proper language, designed and implemented as such with all the appropriate features. 2. Keep the "model operations" as a simple and limited DSL only for basic cases, and make it easier to branch out into a proper existing programming language (probably Java) as soon as things go beyond basic operations. I would tend towards option 2, *except* for the issue that as soon as you introduce Java, you lose the flexibility of instant feedback when developing the VSM with a session in the same runtime. CC-ing Cédric to get his opinion on this.
