Em Thu, 02 Oct 2008 13:10:23 -0300, Alex Kotchnev <[EMAIL PROTECTED]>
escreveu:
5. resolving template/component class names:
This one seems interesting, certainly some variation in the allowed
naming
conventions seems nice if it's configurable (e.g. a naming strategy)
I don't know whether I agree, even if that's pluggable (something like an
alias override). Tapestry 5 has gone in the path of defining some
standards that must be followed and I think of it as a plus. I really love
the 1:1:1 URL-page-template relationship in Tapestry 5. It makes it very
simple and straightforward to find anything related to a page.
> 1. User .tpl instead of .tml. This way there is also no problem with
> syntax highlighting in most editors.
This one seems quite arbitrary, .tml seems just as tood as .tpl, which
"most editors" are you talking about ?
I see no reason for changes.
> 3. Make the Layout component the default component that is always
used if
> not otherwise specified.
> This saves 2 lines of code in all page templates.
A step further : it would be nice if a page could specify either in the
template or in the java class which border component to use. Grails for
example uses Sitemesh layouts, and each rendered page (gsp) can specify
the layout to use .
I disagree.
You can accomplish the same using a Layout component with n t:blocks, one
for each "theme". This Layout would have a non-required parameter
specifying what theme to use.
I really like the idea that templating (in the Layout component sense) in
Tapestry 5 is made through an ordinary component, no through some one more
special mechanism that must be learned.
> 4. Allow the use of templates without having to have a corresponding
Java
> class for it.
This would certainly be nice, as on a small project that I do (that for
now only has little functionality) I already have a whole bunch of dumb
java
classes.
Tapestry 4 (and maybe previous versions too, but I haven't used them) were
exactly like you're asking, but Howard dropped them in Tapestry 5 in order
to simplify things, not having two different paths to reach the same goal.
Of course, he can speak way better to me why he had done that. :)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
Consultor, desenvolvedor e instrutor em Java
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
