Wow - thanks for the full coverage response !
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.
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.
(now in T5 one could say: when using <t:comp - no tag, when using <div
t:type= do render tag...)
Cheers,
Ron
Ryan Holmes wrote:
On Jan 28, 2007, at 3:42 PM, RonPiterman wrote:
Ryan Holmes wrote:
This subject has come up in the past with no real conclusion, but it
did seem like there was consensus on at least one point. Namely, that
an If/Else/For component should automatically emulate its template
tag if the tag is anything other than a span or div (i.e.
tag-dependent rendering/emulation).
seems like a real strange thing to me. Either you render a Tag by
default or you don't, why exclude span or div? rule like "it makes
that unless..." are a good recepie for many postings in this group...
why not just take the 4.1 strategy: use renderTag=true by default?
Cheers,
Ron
I'm talking about changing the 4.1 behavior.
This all started with a seemingly harmless suggestion from Howard: have
If/Else components render their template tags by default unless the
template tag is a span. Several people (including myself) noted that the
span exemption should also apply to div tags since divs are more or less
semantically equivalent (i.e. span and div are both generic containers)
and are often required to maintain well-formed templates.
The reason to even get into this in the first place was to support the
standard use cases of template tags with If and Else. When you do
something like <table jwcid="@If" ...> in your template you almost
always want to render that table tag. When you do <span jwcid="@If" ...>
you usually want a pure logic component (i.e. you don't want to render
the span).
While renderTag=true seems like a good idea, it basically just reverses
the 4.0 behavior without providing real value. In other words, where you
used to have to add "element=..." to about 50% of your If/Else tags you
now have to add "renderTag=false" to the other 50%. This 50/50 ratio
bears out over the 160+ page and component templates in the 4.0 app my
company is working on and I believe Andy reported a similar ratio in his
templates. The renderTags property was added to address the fact that
it's just as easy to argue for renderTag defaulting to false as it is to
argue for the current default of true.
It's not hard to imagine that some people will have a 60/40 or 70/30
split one way or the other in terms of rendering vs. non-rendering If
and Else components. The only pattern that does seem to exist is that
you almost always want the If or Else to render when you're using
something other than span or div in your template, so why not support
that by default?
renderTag=true actually works out pretty well for For components, at
least in my experience. But there's a good argument to be made for
consistent tag rendering behavior across If, Else and For.
My initial reaction to tag-dependent behavior was the same as yours:
it's too complicated and will confuse beginners. However, the current
behavior is a compromise that also leads to an "it works like this
unless..." situation. It depends on the global setting for renderTags
and whether or not it is overridden for a particular page or component,
etc. In addition, the renderTags property introduces another problem in
that the rendering behavior of library components that use If/Else/For
will change based on your global setting.
I think it would be better to have a simple, consistent rule (even if
the rule is tag-dependent) rather than forcing a user to figure out the
implications of changing global behavior. Any potential confusion can be
mitigated through clear documentation and consistent application of the
behavior.
By way of comparison, look at the behavior of the Insert component in
4.0, which will render its template tag if you specify a class
attribute. This is pretty weird, but I don't recall many questions about
it because it usually does what you want.
It seems to me there are a couple of basic questions here that we could
focus on. One is the point that you bring up: is tag-dependent rendering
simply too confusing to ever consider adding to the framework? The other
is really a precursor to that: is the assumption/observation that divs
and spans usually imply "don't render" while other tags usually imply
"do render" correct?
-Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
