You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Leonardo Quijano Vincenzi <le...@dtqsoftware.com> on 2006/03/11 05:05:55 UTC

Tapestry-DHTML

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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org