Who would have thought this much discussion would come out of this :-)
Anyway, some more comments from me :
On Thu, Oct 2, 2008 at 1:51 PM, Thiago H. de Paula Figueiredo <
[EMAIL PROTECTED]> wrote:
> 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.
I would think (having seen the other small interfaces that are in T5)
that there already is a service that performs some of this (e.g. the part
that shortens the URLs) strategy of mapping class names to page names to
URLs. Thus, it might be just an issue of documenting what needs to be
overriden and implemented if I wanted to have the FooBar.class map to
foo-bar.html instead of FooBar.html
>
> > 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.
I am not advocating the usage of some "other" magical framework to manage
the layouts. My point is this : how many applications do you have that DO
NOT use a common layout ? To take it even further, how many application did
you create where creating the layout component (even a basic one) was not
one of the first thing you did in the prototype ? I think that the fact that
I often start w/ some kind of layout, and in the end *always* end up using a
layout, makes it very hard to explain why T5 doesn't have a layout component
in the framework core (instead of letting it sit on the wiki).
Daniel Jue mentions that having a default layout would be an extra caveat
for newcomers and I have to disagree with that very strongly : I think that
not having some kind of layout support is an extra (and unnecessary) hurdle
that a newcomer has to clear, and instead of being an extra caveat providing
a default layout implementation would be a sensible default (yeah, all that,
opinionated software, convention over configuration, etc)
I do agree with the statement that it is nice that the layout in Tapestry is
just another component, and there is no "other" magical framework to learn
(although if there was, considering how much magic already happens in T5,
one more spell wouldn't break the camel's back). It seems like the Layout
component on the wiki that can set the title on the page, a map of key/value
pairs that the client page can set for the usage by the layout, and the
ability contribute some blocks from the page to the outside layout would be
very valuable.
Now, whenever you have to create a complex layout (like the one you
described, with a bunch of themes and such), then you'll definitely have to
create your own, but at least it wouldn't be the first thing you have to do
when you start working w/ T5 . People often talk about the steep learning
curve w/ Tapestry, and I feel that this is one of the things that
contributes to it.
>
> > 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. :)
I fail to see how having 2 artifacts (an empty class and html) is simpler
than having just one, especially when the java class is just an empty class.
In the little project that I do, I do have a bunch of pages that are
composed of mostly static text, but for which I like being able to apply the
same layout as all the other pages.
Cheers,
Alex Kotchnev
