Some ideas for the client-side component guys:
Specially with the new "AOP" kind-of infrastructure that could be built
with Tapestry, I think client-side code can be moved to a specific
sub-project of Tapestry (like Tapestry-annotations for example). I have
some ideas that would work great as client-side code, but the current
organization of the Tapestry code-base has this kind of code scattered
around.
For example, I would like to be able to use client-side things like these:
- Validation: Of course, I know it's already there :P. I'm talking about
polishing it, and including for example several ways of doing
validation. I like the "onblur" approach, where you edit text in a page,
and when you tab out of an invalid field, the label is set to red, or a
exclamation mark is added besides the field. We could even add "Ajax
validators" that asks the server if a field is valid and sets the
exclamation mark as specified before. The current situation is that
validation is still a bit stiff (including Tacos one), and putting it in
a separate sub-project would ease the development of more flexible
implementations.
The real kicker is when you have your int/date fields automatically
validated without specifying the "validator" parameter. Or even
including automatic Hibernate / Commons / Spring Validator integration.
But that's a mix of server and client side code that could be done using
AOP techniques.
- Formatting: This is simple, when a user enters a number or a date and
changes the field, a javascript formatter kicks in and formats the
value. This, again, would be done transparently, without specifying a
"clientSideFormat='.....'" parameter, but using the translator
configuration to generate JS.
- Common DHTML: A lot of small DHTML functions could be integrated as
Tapestry components / parameters. Things like javascript expression
evaluators (you're entering some money fields, and a total below is
updated *without* going Ajax), special effects, etc, would go here.
- Ajax: The "cool" part of the project, the Tacos stuff, dojo event
connection, etc.
- Masking: Perhaps I have an Integer field, and when Tapestry generates
the textfield, it automatically renders a JS mask that allows only
numbers to be specified.
Of course, for the people concerned about JS file size, these should be
actually be configurable at a global and page level. Or even not
including the Tapestry-DHTML project at all! But that should be easier
to implement.
What do you guys think?
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
