|
|
|
|
| Re: [Xpand] dynamic EXPAND statement [message #725264 is a reply to message #725228] |
Wed, 14 September 2011 11:00   |
 Volker Wegert
Messages: 182
Registered: July 2009 |
Senior Member |
|
|
Karsten,
Am 14.09.11 12:08, schrieb Karsten Thoms:
> I don't think that we would realize this feature. It does not fit to the
> way Xpand works.
Thanks for the clarification.
> If you need to work around, follow the instructions Jörg was pointing at.
I think I've got it working now, but I'm wondering whether I could
improve this a bit more:
My current setup consists of a three-step workflow:
1. Generate an intermediate model from a source model
2. Generate code from both the source and the intermediate model
3. Read the generated code and insert it into attributes of the
intermediate model
(I'm not generating Java code here, but ABAP - that has to be treated in
a very different way. The next steps involve computing a dependency
graph and generating the individual objects of the intermediate model in
reverse order, but I digress...)
This approach in itself is already a workaround - I'd love to get rid of
the intermediate "generate code, write it to files and read the files"
steps and call the Xpand templates directly from Xtend, storing the
result into attributes of the intermediate model. So if there was a way
to write
method.setBody(expandTemplate("Foo:Bar", x, y)) ->
and expandTemplate would include some handwavium to evaluate the Xpand
template and return the result, that would be cool. Is it possible to
register some kind of outlet that does not write the generated source to
a file but that loops back to the class that runs the evaluation?
Thanks
Volker
--
* Volker Wegert * http://www.volker-wegert.de/contact *
|
|
|
| Re: [Xpand] dynamic EXPAND statement [message #725277 is a reply to message #725264] |
Wed, 14 September 2011 12:12 |
|
> Is it possible to
register some kind of outlet that does not write the generated source to
a file but that loops back to the class that runs the evaluation?
In principle, yes. It would actually be OutputImpl that you should subclass. The pushStatement() method gets the current XpandExecutionContext, which might help you to get back to your evaluating class (or you have to register a variable in it). Then you might want to overwrite writeAndClose() to avoid actually writing the file.
This Output implementation is passed to the constructor of XpandExecutionContextImpl.
That's roughly were to look.
~Karsten
Need professional support for Xtext, EMF, Eclipse IDE?
Go to: http://devhub.karakun.com
Twitter : @kthoms
Blog : www.karsten-thoms.de
|
|
|
|
| Re: [Xpand] dynamic EXPAND statement [message #725323 is a reply to message #725305] |
Wed, 14 September 2011 14:14 |
|
You can guess from the complexity of the workaround that your approach is something that is not the typical way to use Xpand. The natural way is to use static template invocation. But if really need it, an approach that works somehow is the right one.
~Karsten
Need professional support for Xtext, EMF, Eclipse IDE?
Go to: http://devhub.karakun.com
Twitter : @kthoms
Blog : www.karsten-thoms.de
|
|
|
| Re: [Xpand] dynamic EXPAND statement [message #725355 is a reply to message #725323] |
Wed, 14 September 2011 14:52 |
Volker Wegert
Messages: 182
Registered: July 2009 |
Senior Member |
|
|
Am 14.09.11 16:14, schrieb Karsten Thoms:
> You can guess from the complexity of the workaround that your approach
> is something that is not the typical way to use Xpand. The natural way
> is to use static template invocation. But if really need it, an approach
> that works somehow is the right one.
I'd love to restrict myself to static template invocations with some AOP
magic, but that doesn't seem to be possible in this case - at least not
without duplicating large parts of the logic involved. I can only tell
which templates I have to invoke after the intermediate model is
generated, because during the generation of this model, a lot of
conditions are evaluated that control which parts of the code need to be
generated. I could duplicate that and make the decisions during the code
generation as well as during the model transformation, but that would be
even less maintainable.
On the other hand, everything I do here seems to be a less-than-typical
way to do stuff. You can take a look at
http://www.volker-wegert.de/en/mdd-sap-r3 if you're interested, I've
blogged about the entire process some time ago...
Thanks anyhow, I think I've got something to work with now.
Volker
--
* Volker Wegert * http://www.volker-wegert.de/contact *
|
|
|
Powered by
FUDForum. Page generated in 0.03180 seconds
] 
Search
Help
Register
Login
Home
