On Jan 30, 2007, at 2:07 AM, Jonas Maurus wrote:
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Pretty much agree with everything you said. The element parameter is
not only very useful in a component, but has the benefit of simple
behavior. Currently (in 4.1.x), the element parameter takes
precedence over renderTag in If/Else/For and I think it should remain
that way (for backwards compatibility as well as clarity).
The tag-dependent rendering I'm talking about would only happen when
no element is specified. While this would cause unexpected output in
a few 4.0 templates, I think in the vast majority of cases template
authors use a span or div in the template for If/Else/For components
that shouldn't render a tag. The main purpose of the new behavior
would be to eliminate the other common, needlessly repetitive cases,
e.g.
<h1 jwcid="@If" ... element="h1">, <tr jwcid="@For" ...
element="tr">, etc.
Keep in mind that, as things stand, all If/Else/For components that
use a div or span but have no element parameter will be rendered by
default in 4.1 (this can be changed globally or in individual pages/
components with the renderTags property). So people upgrading from
4.0 either have to globally set renderTags=false or go through all
their templates and add renderTag=false all over the place. Tag-
dependent rendering would, imo, be much friendlier in terms of
backwards compatibility than the current renderTag=true default
behavior, and more useful in the long run.
As far as spreading element to other components, I don't really have
an opinion either way.
-Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
