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 Tue, 30 Jan 2007 09:08:46 GMT
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:
> 
> 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 parameter.
> 
> -Ryan


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


Mime
View raw message