On 1/16/07, Mind Bridge <[EMAIL PROTECTED]> wrote:
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.
And this is just a one or two line change to accomplish.
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.
I want to find away to avoid a switch or configuration. That's the
kind of approach taken in the past with Tapestry that has made it hard
to document and configure. I've recently read "The Paradox of Choice"
as well as some of Joel Splotzky's blogs, which really identify
punting difficult decisions to the users (under the guide of choice)
as just being weak willed and lazy.
I think the current plan will work well for both groups you mentioned:
1) Informal parameters in the template default to "literal:"
2) Informal parameters in the Java class default to "prop:"
3) Most formal parameters default to "prop:"
4) Rarely, parameters will have a different prefix.
Of course, with CodeAndGo (tm), you'll just get an error that should
identify the exact line, give youa clue as to what occured, you fix it
and your back running in, like, two seconds.
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...)
This is a natural for a Mixin. A RenderIf mixin could easily control
this, evaluating a parameter and preventing the rendering of the
affected components (including its body and template).
The render/mixin architecture is quite powerful and robust, though its
going to take some time, and alot more documentation and examples, for
the full community to realize the potential.
Best regards,
-mb
--
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]
