|
|
|
Re: [QVTO] Adding variables to QVTO environment [message #493252 is a reply to message #493235] |
Fri, 23 October 2009 22:33 |
Eclipse User |
|
|
|
Originally posted by: dvorak.radek.gmail.com
Hi Derek,
If you want to reference a variable in QVTO, it must be defined somewhere.
You can't reference an external global variable in QVTO source file, as
the standard
QVTO compiler would have no idea what it is.
The configuration properties are declared in QVTO concrete syntax and
are also exposed to external clients for initialization.
A clear contract isn't it? What would be the benefit of environment
variables here?
However, configuration properties are typically used with data type values.
If you intend to pass model objects, would not it be rather an input model?
It's easy to get access to it and keep in a module wide property.
This way you can create a model of your data you need to store in an
environment, all would be legal QVTO ;-).
Regards,
/Radek
On Fri, 23 Oct 2009 20:26:25 +0200, Derek Palma <derek.palma@gmail.com>
wrote:
> The properties could be. I was not sure if they were intended for the
> same purpose. I just need a way to inject named and typed variables into
> the environment. I also would prefer to inject the variables using the
> Environment API if possible and it seems QVT is using this.
>
> "Alex" <alex.leites@gmail.com> wrote in message
> news:hbsqgt$ctr$1@build.eclipse.org...
>> Would QVT configuration properties be what you are looking for? These
>> can be declared and used in .qvto and can be set via ExecutionContext
>> passed to the TransformationExecutor.
>
|
|
|
Re: [QVTO] Adding variables to QVTO environment [message #493306 is a reply to message #493252] |
Sat, 24 October 2009 15:47 |
Derek Palma Messages: 141 Registered: July 2009 |
Senior Member |
|
|
Hi Radek,
You make some good points. I think my odd request is because I think about
OCL/QVT differently. For me it is like a scripting language. In fact I
generally don't use the QVT editor other than for very complex things. I
just have strings of text which get wrapped with a main() and get invoked on
the fly. So QVT could see whatever is available at compile time at that
moment. But I see how it is different than OCL.
The reason I make the request is that I like the idea of having predefined
variables like "self" and "result". To me self is an operand and result is
the result some computed result on the operand. So for my application, in
OCL, for example, I pass 'policy' as a variable which is a 'contextual
operand', i.e. the policy to apply in a transformation. I can certainly pass
it as an input model. It is more a matter of syntax, as I just reference
parts of policy with OCL, it gives me all the information.
However, there is also one problem I have faced when calling QVT compared to
OCL. The API requires the caller to know the number of arguments to the
main() before he can invoke it. This certainly makes sense from a type
safety point of view, but it is kind of annoying if you use QVT often from
your java code to invoke transformations with different sets of input/output
params. I actually have to store the description of the transformation
somewhere so I know how to invoke it. So the real reason for my question is
really motivated by this issue. With OCL, there is no typed interface, it
just assumes self and any other variables that are present in the
Environment can be reference or you get a syntax error. I was looking for a
way to achieve a similar invocation syntax. The nice thing about the OCL API
(and this is really the only reason I still use OCL versus just completely
switching to QVT) is that I can have an EOBject and perform an OCL
query/constraint on it by just writing a query string with one line of java
code: oclConstraint("self.someVar <> policy.someOtherVar", varBindingMap).
Of course my reason for using QVT is that not all such constraints can be
written conveniently in OCL. Actually, I end up writing queries and helpers
in QVT libraries and calling them from OCL anyway. But, again, I was just
looking for a way to simplify the calling syntax. I try to avoid the EMF
Java API for evaulating and updating EObjects.
It looks like configuration properties are good for predefined variable that
can change at runtime. So this could work for me. I must know the variable
name in advance regardless when I generate my OCL/QVT text.
Derek
"radek dvorak" <dvorak.radek@gmail.com> wrote in message
news:op.u19yafkd12y5f2@kliste.local...
> Hi Derek,
>
> If you want to reference a variable in QVTO, it must be defined somewhere.
> You can't reference an external global variable in QVTO source file, as
> the standard
> QVTO compiler would have no idea what it is.
>
> The configuration properties are declared in QVTO concrete syntax and
> are also exposed to external clients for initialization.
> A clear contract isn't it? What would be the benefit of environment
> variables here?
>
> However, configuration properties are typically used with data type
> values.
> If you intend to pass model objects, would not it be rather an input
> model?
> It's easy to get access to it and keep in a module wide property.
> This way you can create a model of your data you need to store in an
> environment, all would be legal QVTO ;-).
>
> Regards,
> /Radek
>
>
> On Fri, 23 Oct 2009 20:26:25 +0200, Derek Palma <derek.palma@gmail.com>
> wrote:
>
>> The properties could be. I was not sure if they were intended for the
>> same purpose. I just need a way to inject named and typed variables into
>> the environment. I also would prefer to inject the variables using the
>> Environment API if possible and it seems QVT is using this.
>>
>> "Alex" <alex.leites@gmail.com> wrote in message
>> news:hbsqgt$ctr$1@build.eclipse.org...
>>> Would QVT configuration properties be what you are looking for? These
>>> can be declared and used in .qvto and can be set via ExecutionContext
>>> passed to the TransformationExecutor.
>>
|
|
|
Powered by
FUDForum. Page generated in 0.03094 seconds