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).
I started working on a patch to implement this (thinking it might
help to at least push the discussion forward) but quickly ran into a
problem with the renderTag parameter.
If certain template tags render by default and others do not, the
meaning of the renderTag parameter becomes unclear. For instance,
what should happen if renderTag=true but the template tag is a span?
If the answer is that renderTag should take precedence, then we're
back to having to explicitly set renderTag every time we want a "pure
logic" If/Else/For (assuming renderTag defaults to true). If the tag-
dependent behavior takes precedence then renderTag is ignored in one
case or the other. Either renderTag=false is ignored for non-span/div
tags or renderTag=true is ignored for spans and divs.
The renderTags configuration property seems to only complicate the
situation. It either overrides and interferes with the tag-dependent
behavior or gets re-interpreted as "turn on tag-dependent behavior",
which leads back to the ambiguous renderTag=false case mentioned above.
So here's what I have in mind at the moment: implement the tag-
dependent behavior, remove the renderTag parameter and the renderTags
property and un-deprecate the element parameter to handle edge cases
(e.g. you want a span or div to render or you want to emulate a
different tag than what's in the template). This should give us the
correct default behavior in most cases and provide an unambiguous way
to override that behavior (via the element parameter).
What I'm advocating is clearly a "convention over configuration"
approach that might not be to everyone's taste, but it does have the
advantages of being convenient, consistent (you don't have to think
about how your component will behave with renderTags=false, etc.),
relatively simple and more backwards compatible with 4.0 than the
current behavior.
Thoughts?
-Ryan
To unsubscribe, e-mail: dev-unsubscribe (AT) tapestry (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tapestry (DOT) apache.org

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 started working on a patch to implement this (thinking it might help
to at least push the discussion forward) but quickly ran into a problem
with the renderTag parameter.

If certain template tags render by default and others do not, the
meaning of the renderTag parameter becomes unclear. For instance, what
should happen if renderTag=true but the template tag is a span? If the
answer is that renderTag should take precedence, then we're back to
having to explicitly set renderTag every time we want a "pure logic"
If/Else/For (assuming renderTag defaults to true). If the tag-dependent
behavior takes precedence then renderTag is ignored in one case or the
other. Either renderTag=false is ignored for non-span/div tags or
renderTag=true is ignored for spans and divs.

The renderTags configuration property seems to only complicate the
situation. It either overrides and interferes with the tag-dependent
behavior or gets re-interpreted as "turn on tag-dependent behavior",
which leads back to the ambiguous renderTag=false case mentioned above.

So here's what I have in mind at the moment: implement the tag-dependent
behavior, remove the renderTag parameter and the renderTags property and
un-deprecate the element parameter to handle edge cases (e.g. you want a
span or div to render or you want to emulate a different tag than what's
in the template). This should give us the correct default behavior in
most cases and provide an unambiguous way to override that behavior (via
the element parameter).

What I'm advocating is clearly a "convention over configuration"
approach that might not be to everyone's taste, but it does have the
advantages of being convenient, consistent (you don't have to think
about how your component will behave with renderTags=false, etc.),
relatively simple and more backwards compatible with 4.0 than the
current behavior.

Thoughts?
-Ryan

To unsubscribe, e-mail: dev-unsubscribe (AT) tapestry (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tapestry (DOT) apache.org

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. 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: dev-unsubscribe (AT) tapestry (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tapestry (DOT) apache.org

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:

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. 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: dev-unsubscribe (AT) tapestry (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tapestry (DOT) apache.org

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: dev-unsubscribe (AT) tapestry (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tapestry (DOT) apache.org

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:

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: dev-unsubscribe (AT) tapestry (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tapestry (DOT) apache.org

1/30/07, Ryan Holmes <ryan (AT) hyperstep (DOT) comwrote:

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 would also like the element parameter not to be deprecated. IMH, T5
should be the next major break, if necessary. 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: dev-unsubscribe (AT) tapestry (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tapestry (DOT) apache.org

Jan 30, 2007, at 2:07 AM, Jonas Maurus wrote:
I would also like the element parameter not to be deprecated. IMH, T5
should be the next major break, if necessary. 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: dev-unsubscribe (AT) tapestry (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tapestry (DOT) apache.org

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: dev-unsubscribe (AT) tapestry (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tapestry (DOT) apache.org

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: dev-unsubscribe (AT) tapestry (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tapestry (DOT) apache.org