Re: [Andromda-devel] AndroMDA 3.0 - vision for the next generation

[Richard K. <ku...@ti...>]

On Monday 04 August 2003 11:51, Lendvai Attila wrote:
> :: Moving the complexity from templates to Java sources may or
> :: may not be a gain.  This way, one could change the generated
> :: source only by tinkering with Java sources.  On the other
>
> just writing down my toughts, i don't want to push it too hard...
> especially because i can't see everything clearly, yet. but having the
> possibility to write the templates in interpreted java invalidates this
> entire question. you can easily move the code between the template api
> (compiled java) and the templates themselves (interpreted java), if you
> don't use beanshell's script-like language features. (even if you do,
> you can keep the code in interpreted java realm as a library) of course
> factoring out stuff into the template api is a good thing anyways, if
> something is used in more then one template. and if we write the
> templates in java, then doing this factorization is much easier then
> with velocity.
>
> what do you think?

=46rom my experience (some years of working with and designing template bas=
ed=20
frontends for web applications :-) templates should be kept as simple and a=
s=20
close to the final result as possible.=20

This means especially that templates should contain as little logic as=20
possible (ideally, no logic at all), and to push the "intelligence" to the=
=20
template support classes. As a rule of thumb, it's probably best to only us=
e=20
the following constructs in templates:
=2D Strings that are dynamically generated by the model. E.g. "$entity.name=
" in=20
velocity.
=2D Loops that iterate over a collection of things from the model. E.g.=20
"#foreach ($method in $entity.createMethods)"
=2D Conditionals to show parts of the template based on querying a property=
 of=20
the model. E.g. "#if ($entity.isAbstract)"

If you do anything else in the template (especially if you find yourself=20
setting variables and calling methods with arguments), IMO you should think=
=20
long and hard if it's not better to push this part to the support class.

As I see it, following these rules has two advantages: First, it makes for=
=20
simpler templates (always a good thing, as templates are a nightmare to=20
debug), and second, it draws a clean line between the template itself (the=
=20
view in MVC parlance) and the support classes that feed it information from=
=20
the model (in MVC, the model as well).

To support this statement, have a look at the new EJB cartridge, expecially=
=20
EntityBean.vsl. I'm violating these rules there (and no, I don't have a rea=
l=20
excuse), and the templates are already a big, unmaintainable mess.

And yes, I intend to refactor the EJB templates ASAIFTT (as soon as I find =
the=20
time :-)

Bye,

Richard
=2D-=20
Richard Kunze=20

[ t]ivano Software, Bahnhofstr. 18, 63263 Neu-Isenburg
Tel.: +49 6102 80 99 07 - 0, Fax.: +49 6102 80 99 07 - 1
http://www.tivano.de, ku...@ti...=20