| Invocation Framework [message #1259] |
Fri, 10 November 2006 17:24  |
Eclipse User |
|
|
|
Originally posted by: gkevorki.sybase.com
Hello,
I have a question about the invocation framework.
One of the initial stated goals is:
"Invoke a component supplied template independently of the template language
used"
Is interop between generation models written in different template languages
the actual goal? If so, doesn't this imply defining some sort of reflection
API to be implemented by language providers while at the same placing some
assumptions over the actual languages?
How would this vision fit with JET? Is the distinction which is made between
template & code generator relevant in JET's case?
Thanks,
Gabriel Kevorkian
Senior Software Engineer
PowerDesigner R&D
Sybase, Inc.
|
|
|
|
| Re: Invocation Framework [message #2188 is a reply to message #1307] |
Tue, 14 November 2006 11:05  |
| Eclipse User |
|
|
|
Originally posted by: gkevorki.sybase.com
> what do you mean by "generation models"?
Let's say a set of templates. An .xpt file in your case.
Gabriel
Gabriel Kevorkian
Senior Software Engineer
PowerDesigner R&D
Sybase, Inc.
|
|
|
| Re: Invocation Framework [message #2222 is a reply to message #1259] |
Wed, 15 November 2006 13:33 |
 Paul Elder
Messages: 849
Registered: July 2009 |
Senior Member |
|
|
Gabriel:
The goal is NOT to have templates from one language invoke templates in
another language.
Rather, the statement is trying to capture the idea that some system may
employ a template to produce some artifact, and the implementer of that
system should be able to invoke the template using M2T supplied API such
that:
1) A user may replace the template with his own implementation
2) The user supplied implementation may use a language different than the
initial implementation.
I view this case to be just a degenerate case of a group of templates, which
in the JET world, I call a transformation. To restate this from the point of
view of a transformation, I would say: A system may employ a transformation
to produce some set of artefacts, and the implementer of that system should
be able to invoke the transformation using a M2T supplied API such that:
1) A user may replace the transformation with his own implementation
2) The user supplied implementation may use a language different than the
initial implementation.
None of the above requires a language to support templates from another
language, nor does it require systems that consume templates or
transformations to enable user customization.
What it does require of template languages is a common meta-model for
template/transformation input. The proposal considers this to be EMF,
although I know that both JET and XPand can handle other meta-models, as
well.
Paul
"Gabriel Kevorkian" <gkevorki@sybase.com> wrote in message
news:ej2cl2$lm8$1@utils.eclipse.org...
> Hello,
>
> I have a question about the invocation framework.
>
> One of the initial stated goals is:
>
> "Invoke a component supplied template independently of the template
> language used"
>
> Is interop between generation models written in different template
> languages the actual goal? If so, doesn't this imply defining some sort of
> reflection API to be implemented by language providers while at the same
> placing some assumptions over the actual languages?
>
> How would this vision fit with JET? Is the distinction which is made
> between template & code generator relevant in JET's case?
>
> Thanks,
>
> Gabriel Kevorkian
> Senior Software Engineer
> PowerDesigner R&D
> Sybase, Inc.
>
|
|
|
| Re: Invocation Framework [message #2281 is a reply to message #2222] |
Thu, 16 November 2006 09:05 |
| Eclipse User |
|
|
|
Originally posted by: gkevorki.sybase.com
Thanks, Paul, for the clarification.
Gabriel
"Paul Elder" <pelder@ca.ibm.com> wrote in message
news:ejf4uk$99r$1@utils.eclipse.org...
> Gabriel:
>
> The goal is NOT to have templates from one language invoke templates in
> another language.
>
> Rather, the statement is trying to capture the idea that some system may
> employ a template to produce some artifact, and the implementer of that
> system should be able to invoke the template using M2T supplied API such
> that:
>
> 1) A user may replace the template with his own implementation
> 2) The user supplied implementation may use a language different than the
> initial implementation.
>
> I view this case to be just a degenerate case of a group of templates,
> which in the JET world, I call a transformation. To restate this from the
> point of view of a transformation, I would say: A system may employ a
> transformation to produce some set of artefacts, and the implementer of
> that system should be able to invoke the transformation using a M2T
> supplied API such that:
>
> 1) A user may replace the transformation with his own implementation
> 2) The user supplied implementation may use a language different than the
> initial implementation.
>
> None of the above requires a language to support templates from another
> language, nor does it require systems that consume templates or
> transformations to enable user customization.
>
> What it does require of template languages is a common meta-model for
> template/transformation input. The proposal considers this to be EMF,
> although I know that both JET and XPand can handle other meta-models, as
> well.
>
> Paul
>
> "Gabriel Kevorkian" <gkevorki@sybase.com> wrote in message
> news:ej2cl2$lm8$1@utils.eclipse.org...
>> Hello,
>>
>> I have a question about the invocation framework.
>>
>> One of the initial stated goals is:
>>
>> "Invoke a component supplied template independently of the template
>> language used"
>>
>> Is interop between generation models written in different template
>> languages the actual goal? If so, doesn't this imply defining some sort
>> of reflection API to be implemented by language providers while at the
>> same placing some assumptions over the actual languages?
>>
>> How would this vision fit with JET? Is the distinction which is made
>> between template & code generator relevant in JET's case?
>>
>> Thanks,
>>
>> Gabriel Kevorkian
>> Senior Software Engineer
>> PowerDesigner R&D
>> Sybase, Inc.
>>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.14735 seconds
] 
Search
Help
Register
Login
Home
