I've probably mis-understood the example / or am just being too
conservative. My misgivings come in thinking that we're going to be
fighting an uphill battle getting people who are normally used to
thinking in terms of:
if () {
} else if () {
} else {
}
to think in terms of:
if () {
else {
}
}
It makes sense from a component development / template parsing
perspective, but may be one of those things that makes writing some
slightly more complicated logic in the component is worth the
abstraction not leaking out into the template code. At least in this
instance.
On 1/14/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
On 1/13/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
> Probably not adding anything useful to the conversation, but is the
> intention that this is just an example of how to use nested parameter
> block controls? If so, cool!
Glad you like it.
>
> If it is an example of the "real" If component (I can't imagine it is,
> but who knows) then I'd be very concerned about the example. Not from
> the component writing ease of use standpoint, but more from the
> template writing point of view / readability.
As of right now, this is valid. I'm not sure I follow your objection.
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
