tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Holmes <r...@hyperstep.com>
Subject Re: [T4] If/Else/For tag rendering behavior
Date Tue, 30 Jan 2007 06:09:49 GMT

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  


To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

View raw message