My usage of If/Else and For in a fairly large Tapestry app mirrors
yours: it comes down to about 50/50 (except with For's which I
usually want to render the tag I'm using in the template).
The only problem I have with the original suggestion is that I don't
think spans should be treated differently than divs. My non-rendering
If and Else components use divs when necessary to keep the template
well-formed, which is fairly often. btw, I'm not pushing valid HTML
templates here, just talking about well-formed templates that don't
cause, for instance, a WTP HTML validation error.
To put it another way, it seems awkward to treat span and div
differently since they are both generic container elements. When I'm
wrapping, say, a form component in a non-rendering If, I'm going to
use a div because it's required to maintain a well-formed template --
not because I want a rendering vs a non-rendering If.
So how about this:
1) renderTag defaults to false for spans and divs.
2) renderTag defaults to true for any other tag.
3) The renderTags config parameter goes away.
4) The element parameter is always honored, regardless of the
template tag (this is the current behavior).
5) These rules apply equally to If, Else and For.
I think these rules would provide the convenience Howard intended
with a minimal loss of backwards compatibility. Unless I'm missing
something, only somewhat bizarre (and hopefully rare) templates would
break in 4.1. So the following in a 4.0 template:
<td jwcid="@If" condition="ognl:myCond">
would now render a td tag and likely break the page. However, an
obvious response to a complaint about this behavior would be " please
take this opportunity to clean up your template" ;)
So at this point I guess I'm simply echoing Howard's original
suggestion with the caveat that span and div tags should both be non-
rendering by default. Is there a good reason for treating divs
differently?
I originally didn't like the idea of treating any HTML tags as
"magical". After thinking about this a little bit though, I have to
agree with Andy's point that the new behavior will often simply shift
the problem from having to explicitly specify an element to having to
explicitly turn off element rendering.
-Ryan
On Dec 13, 2006, at 6:53 AM, andyhot wrote:
I've found that i haven't gained anything at all from this
"enhancement".
As things were in 4.0.x i had to use element="something" half of
the time
As things are in 4.1.x, i have to use renderTag="false" the other half
of the time
( or set the defaultRenderTags to false, and work as in 4.0.x ).
Esp. when @If or @For components are immediately followed by tapestry
components,
renderTag="false" is a must.
So, since we can allow users to get the old behavior (by setting
defaultRenderTags to false ),
can't we go on with the initial suggestion ( which was "if the
component's tag is span,
honor the element parameter, else honor the component's actual
tag" ) ?
Jesse Kuhnert wrote:
Yeah I was afraid of that...Perhaps we should use the same behavior
for span
AND div, possibly making a note that div will be rendered in 4.2.
On 9/20/06, Paul Ferraro <[EMAIL PROTECTED]> wrote:
I often use <div> tags for these types of components, because
<span> is
not always contextually valid.
The logic you're proposing would cause these extra <div>s to
appear in
my html.
Paul
On Wed, 20 Sep 2006 08:10:56 -0700, "Howard Lewis Ship"
<[EMAIL PROTECTED]> said:
Components which have an "element" parameter (If, For, etc.).
Perhaps we should code it as:
if the component's tag is "span", honor the element parameter,
else honor the component's actual tag
So:
<fieldset jwcid="[EMAIL PROTECTED]" element="fieldset"
condition="ognl:book.name">
could be replaced with
<fieldset jwcid="[EMAIL PROTECTED]" condition="ognl:book.name">
To the same result.
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
--
Paul Ferraro
[EMAIL PROTECTED]
--
http://www.fastmail.fm - Accessible with your email software
or over the web
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andreas Andreou - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
