I Agree with Nick's idea, for every component there should be a
parameter that tells to render it or not (Very good for granularity
of security, links that you don't have access too won't appear etc...)
Too much nesting seems very complicated, I like the Tap 4 way to
handle the if/else, it feels natural. Why would be the problem of
keeping the way Tap 4 handles the if/else ?
The only problem might be of handling if/else in loops :
<if>
<for>
<if>
doSomething
</if>
<else>
doSomethingElse
</else>
</for>
</if>
<else> <--------- How do you store this evaluation, it might
evaluate to the value of the last if in the loop!
doSomthingElseElse
</else>
I don't know if I am very clear with this example. The evaluation of
a condition must be stored relatively to a context (component's
context or page's context) and not globally
Le 16 janv. 07 à 12:36, B.S.Navin a écrit :
I second Nick's idea. It may have many other uses too - like for
example - applying granular security becomes easy. Just include the
condition to check for security in the renderif.
Although, there may still be the need for an elseif, as otherwise,
the conditions of the previous if may need to be repeated here in
the negative.
- Navin
On 16-Jan-07, at 4:21 PM, Nick Westgate wrote:
After rereading the posts on this, my previous post seems redundant.
Jesse's Java nesting example is sufficient to explain why the nesting
feels unnatural. (Not to diminish Howard's amazing ability to re-
invent!)
Kent's "then" parameter is a great idea, but the nesting seems
excessive.
I still think Tapestry already had this one right, yet again. ;-)
BUT ... speaking of nesting, I was reminded of a thought I've had on
occasion when adding conditionals into a template. It would be great
if all components had a conditional attribute - no need to nest more.
eg.
<a t:id="deleteLink">...</a>
->
<a t:id="deleteLink" t:renderif="condition">...</a>
Obviously this is only useful in certain situations, but for complex
templates the less unnecessary nesting of tags the better.
Just thought I'd bring this up while the pot's on the stove.
Anyone else ever wish for this, or think it might be practical?
Cheers,
Nick.
Nick Westgate wrote:
> Jesse's example looks better when you need to add interceding
content.
> The nesting of the else parameter impedes a common use case for
else,
> and if there's no Else component, we end up 'negatively'
violating DRY:
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
