tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From RonPiterman <rpiter...@gmx.net>
Subject Re: [T4] If/Else/For tag rendering behavior
Date Mon, 29 Jan 2007 13:06:16 GMT
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 );


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 

(now in T5 one could say: when using <t:comp - no tag, when using <div 
t:type= do render tag...)


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

View raw message