Hi,
Just to give my take on the matter: I think that in many cases one does
not have to decide whether to do one or the other, but he could do one
AND the other if there is no contradiction. Take the If component for
example: I personally favour Howards' syntax (even though I originally
added the If and Else components in T4) as it is more logical given the
ability to have blocks as parameters in T5. Nevertheless, the current If
and Else components are _bound_ to pop up in a short time, perhaps in an
additional library, as lots of people like them and they are somewhat
more appropriate for some specific circumstances (as indicated in this
thread). Thus, I would suggest to have both the old If/Else in a library
(and define an additional ElseIf component as well), and the new If
syntax in the main framework. I also do not think there needs to be an
argument whether to have a "then" parameter in the new If. In case there
is no "then", then If renders the body, otherwise it renders the "then"
block.
Another use of this principle is the default binding types. I strongly
believe that in the template the default type should always be
"literal", partly because the informal parameters are always "literal",
and the templates will normally be handled by web designers, not
developers. In addition, even if a default type for a given parameter
will save a few keystrokes, once the program becomes large, the
interaction of multiple developers in the project is _guaranteed_ to be
a nightmare. Thus, if you target the small app market,
default-type-per-parameter is quite attractive. For the large-app market
it is unacceptable. However, both could be implemented, and the actual
behaviour could just be controlled by a switch in the configuration --
this would keep both camps happy.
With respect to Nick's suggestion for "renderif": I think this is
actually a larger issue -- the ability to add something like a plug-in
for selection of the components. This is something like AOP for the web.
Basically, a plug-in would act as a proxy (or a filter) in the rendering
process -- it will be a node in the rendering chain. It could decide
whether to continue forward, how it would continue forward, and perhaps
it could render its own content. Thus, you can have a "renderif" plugin
that adds "renderif" argument to the selected components and only
renders the component if the value is true. You can have security
plugins, etc. The definition of the plug-ins would specify which
components they should apply to (I am slightly behind on the Tapestry
development at the moment, so I may be describing something already
existing...)
Best regards,
-mb
Jesse Kuhnert wrote:
That is a ~great~ idea.
You should participate in these discussions more often. ;)
On 1/16/07, Nick Westgate <[EMAIL PROTECTED]> 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]
