As already mentioned, I also don't like the current situation - at first
the renderTag approach
seemed the correct choice, but after heavily working on apps, i see we
haven't gained anything
(neither in terms of code, nor in simplicity)
I feel that I'd prefer (again based on practical usage) an approach
similar to how the
@Insert component was using the class parameter ( though, according to
http://tapestry.apache.org/tapestry4.1/components/general/insert.html ,
this is also deprecated)
But anyway, how about this (regarding @If, @Else, @For):
- keep the 'old' element parameter - if specifed it'll always be used
- if a class parameter is used in those components, render it and use
the tag specified in the template.
Well, better or worse?
Ryan Holmes wrote:
On Jan 30, 2007, at 1:08 AM, RonPiterman wrote:
I am wondering if there is such a usecase of rendering a tag which is
changing, thus, do we really need an element parameter or is it
rather a renderTag flag?
The common use case is inside a component, where you take an element
as a parameter. The contrib Table components use this a lot. I would
say that the primary reason we need the element parameter is because
upgrading from 4.0 would be extremely painful without it. The
secondary reason is that the element parameter provides a capability
that template tag-based rendering simply can't replace (whether the
current renderTag parameter with renderTags config overrides or the
fully automatic behavior I'm talking about).
I think the use case is so rare, and also contrasting to the template
idiom, that we can ignore it - so an element parameter is actually
obsolete.
I think the component use case will exist for the foreseeable future
(in 4.x at least). It probably is rare, but why get rid of something
when it would discourage a lot people from upgrading and when there is
no obvious replacement for its, at least occasionally, useful behavior?
now I would suggest something completley new:
a "suppressTag" parameter - just for the flavour of it, default to
false. div or span or whatever, it doesn't mutter. what does mutter
is how this is grasped by the developer.
suppressTag indicates the default behaviour so everyone knows what we
are dealing with. documentation is obsolete...
I must not get it. I'm seeing something like:
<div jwcid="@If" ... suppressTag="true">
which would just be an inverted renderTag parameter. Did you mean a
configuration property instead of a parameter? Can you give a couple
of examples?
Thanks
-Ryan
---------------------------------------------------------------------
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]
