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]
