|
|
|
|
|
|
|
Re: ATL and JAVA code calling (alternative QVT...) [message #1209677 is a reply to message #1209007] |
Mon, 25 November 2013 16:46 |
cyril dufrechou Messages: 35 Registered: September 2013 |
Member |
|
|
Hi Ronan, Ed,
A field in my model is a property, an attribute, ... an element of my model which is TEXTUAL, and the parser objective is to convert this part of text into model element define in my model itself.
I choose ANTLR because I know it and it was the best way to define a parser from text.
Before deciding to change from ANTLR to XTEXT, I would be assured it can solve my problem...
So can I find somewhere an example of a link between XTEXT and ATL transformation?
And a tutorial for XTEXT => to be able to convert text to model...
Is it the same link possible between XTEXT and QVT? (because I can do the same transformation with QVT-o...)
Because if I have to redesign all my application, I hope to consider all techno!
I tried to explain the best I can my problem, and I don't find how to redesign it to break the loop...
EMF PROJECT ANTLR, XTEXT, ... project
-------------------- --------------------------
| model def | | <textfield> |
| | | || |
| elemX def | | \/ |
| with <textfield> | => | other elem object |
| & | | conform to EMF project |
| other elem def | | EXTERN PARSER |
-------------------- --------------------------
||
\/
ATL (...or QVT)
---------------------------
| the goal is to |
| convert model |
| |
| taking account |
| <texfield> is |
| is not text after ANTLR |
---------------------------
My problem is :
as ATL doesn't know JAVA, I must have EOperation in my model !
but this is why I have a cycle...
and the only needs for the EOperation is ATL request to access <textfield> converted.
|
|
|
Re: ATL and JAVA code calling (alternative QVT...) [message #1209831 is a reply to message #1209677] |
Mon, 25 November 2013 18:25 |
Ed Willink Messages: 7655 Registered: July 2009 |
Senior Member |
|
|
Hi
Xtext is orthogonal to MtoM tools.
Xtext just provides an alternative and often better way of preparing
your models using a textual user interface.
MtoM tools transform them. They should not care how they were prepared.
Regards
Ed Willink
On 25/11/2013 16:46, cyril dufrechou wrote:
> Hi Ronan, Ed,
>
> A field in my model is a property, an attribute, ... an element of my
> model which is TEXTUAL, and the parser objective is to convert this
> part of text into model element define in my model itself.
>
> I choose ANTLR because I know it and it was the best way to define a
> parser from text.
>
> Before deciding to change from ANTLR to XTEXT, I would be assured it
> can solve my problem...
>
> So can I find somewhere an example of a link between XTEXT and ATL
> transformation?
> And a tutorial for XTEXT => to be able to convert text to model...
> Is it the same link possible between XTEXT and QVT? (because I can do
> the same transformation with QVT-o...)
> Because if I have to redesign all my application, I hope to consider
> all techno!
>
> I tried to explain the best I can my problem, and I don't find how to
> redesign it to break the loop...
>
> EMF PROJECT ANTLR, XTEXT, ... project
> -------------------- --------------------------
> | model def | | <textfield> |
> | | | || |
> | elemX def | | \/ |
> | with <textfield> | => | other elem object |
> | & | | conform to EMF project |
> | other elem def | | EXTERN PARSER |
> -------------------- --------------------------
> ||
> \/
> ATL (...or QVT)
> --------------------------- | the goal is to | |
> convert model |
> | |
> | taking account |
> | <texfield> is |
> | is not text after ANTLR |
> ---------------------------
> My problem is : as ATL doesn't know JAVA, I must have EOperation in my
> model !
> but this is why I have a cycle...
> and the only needs for the EOperation is ATL request to access
> <textfield> converted.
>
>
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03630 seconds