For certain use cases, queries require information that is only present at the time the view is created / the model-level transformation is executed. This could, e.g., be a class diagram view that shows only classes from a certain package. In order to not specify a view for each package, we should support the configuration of queries by creating input parameters, which can be used to configure the created view at transformation time. In this example, the view definition would, e.g., take the name of the package as an input parameter. At transformation time, the package name is provided, and the view is created accordingly.
The syntax could like look like in the following example:
export classdiagram to "..."
import "..." as uml
input package : EString
from Class c
where c.package.name == package
create Class
In the example, the keyword input is used to introduce a parameter with the name package. I would propose to allow any meta-class from any of the imported meta-models as type of the parameters. The created input parameter is then, in this example, used in the filter condition of the query creating the Class meta-class in the view type and its instances in the created views.
One limitation of this approach is, that the input parameters, as they are unknown at the time the view type is generated, cannot influence the meta-level elements (meta-classes, feature definitions, etc.).
For certain use cases, queries require information that is only present at the time the view is created / the model-level transformation is executed. This could, e.g., be a class diagram view that shows only classes from a certain package. In order to not specify a view for each package, we should support the configuration of queries by creating input parameters, which can be used to configure the created view at transformation time. In this example, the view definition would, e.g., take the name of the package as an input parameter. At transformation time, the package name is provided, and the view is created accordingly.
The syntax could like look like in the following example:
In the example, the keyword
inputis used to introduce a parameter with the namepackage. I would propose to allow any meta-class from any of the imported meta-models as type of the parameters. The created input parameter is then, in this example, used in the filter condition of the query creating theClassmeta-class in the view type and its instances in the created views.One limitation of this approach is, that the input parameters, as they are unknown at the time the view type is generated, cannot influence the meta-level elements (meta-classes, feature definitions, etc.).