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?
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.
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...
Cheers,
Ron
Ryan Holmes wrote:
On Jan 29, 2007, at 5:06 AM, RonPiterman wrote:
Wow - thanks for the full coverage response !
No problem, thanks for reading the whole thing. I've obviously spent way
too much time thinking about this ;)
You did convince me, except for one thing:
You know this game "the incredible machine", where you have to setup
some items so that a ball will fall down and create a domino effect? I
think whenever programming becomes like that, things are going in the
wrong direction.
What do I mean by that?
When desining an API, you have to be very clear, now would you
like using this method in an API:
/**
* renders the component.
* if renderTag is null, tag will be rendered
* unless tag is "div" or "span", in which case no tag
* will be rendered.
* if rendertag is not null, tag will be rendered depending on
* the boolean value of the renderTag argument
*/
renderComponent( String tag, Boolean renderTag );
ouch.
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 understand the mantra of doing everything to type the minimum, but I
am not a groupie of it. I believe its all about simplicity, and
simplicity does not mean always - do everything to reduce the code to
minimum.
Sure, inflexibly sticking to any mantra usually ends up badly. I'll take
simple over smart any day if smart=overly complicated.
This is as much about "Do What I Mean" as it is about reducing typing. I
think renderTag with a hard-coded default of true (Jesse's original
implementation) was an attempt to DWIM by always rendering tags, but
that didn't turn out to be much better than the old behavior (i.e. *not*
rendering by default).
So, at the risk of repeating myself, a central question here is: how
often would tag-dependent rendering actually do what the user means? If
it's not likely to be at least 80%, it's not worth doing. If it's almost
always correct, it's certainly more useful than the renderTag parameter.
-Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
