tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonas Maurus" <jonas.mau...@gmail.com>
Subject Re: [T4] If/Else/For tag rendering behavior
Date Tue, 30 Jan 2007 10:07:00 GMT
On 1/30/07, Ryan Holmes <ryan@hyperstep.com> wrote:
>
> Agree completely. I don't think the renderTag parameter and tag-
> dependent rendering can coexist in a useful way. The logic I'm
> suggesting is:
>   - if 'element' is not null, render the specified tag (I'm talking
> about the deprecated element parameter here)
>   - otherwise, render the template tag if it's anything but div or span
>
> The logic you're describing assumes that renderTag is a Boolean
> object, but it's currently a primitive (with the default determined
> by the renderTags property, which is configurable at multiple
> levels). Making renderTag a Boolean object and letting it default to
> null would at least allow the tag-dependent behavior to be "added on"
> in a reasonable way. But again, I agree with you -- it's too
> complicated. It ends up feeling like "renderTag=null turns on tag-
> dependent behavior", not to mention the whole tertiary logic issue.
>
> Maybe I wasn't entirely clear initially -- I want to replace the
> renderTag parameter with tag-dependent rendering, and un-deprecate
> the element parameter to handle the edge cases.
>

I would also like the element parameter not to be deprecated. IMHO, T5
should be the next major break, if necessary. Otherwise Tapestry will
gain a track record for breaking existing applications with each and
every release, which I think would be much worse than the gains that
are to be made from having reduced the required typing by 10%.

Currently I'm feeling that this issue is in some ways similar to the
discussion of component-specified default attribute prefixes during T4
development. In the end, scrapping the feature ended up being the
right thing (I was against scrapping it at the time), simply to be
consistent, which is more important than being convenient because it
adheres to the principle of the least surprising behavior.

Not to mention that I've developed a few components that use the
element attribute to be consistent with Tapestry-supplied components
that will have to be changed because otherwise I'm running into the
"use rendertag, expect if you're using in-house components"-problem
with my fellow developers.

Currently all components with an "element" parameter default to not
rendering an enclosing element if the "element" binding is null. Has
refactoring all existing components to use an "element" attribute been
discussed?

best regards from Regensburg, Germany
Jonas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Mime
View raw message