Craig McClanahan wrote:
On 8/9/05, Daniel Perry <[EMAIL PROTECTED]> wrote:
-----Original Message-----
From: Craig McClanahan [mailto:[EMAIL PROTECTED]
PS: It's pretty straightforward to build turbo versions of the Struts
HTML tags that have many of the same features described above. But
that doesn't begin to touch the behavior at input time, where the
component itself deals with details like converters, and completely
eliminates the need for a form bean.
Now it's funny... i was thinking about this the other day.
Why not add to the struts html tags to take validation information? And
while you're at it, why not add typing like type="date" or type="int" or
type="string" to text fields.
Interesting idea. Let's do a bit of mental exploration of what
actually happens to see how practical it is. When does a Struts
custom tag actually execute? Only when the page is being rendered, as
the various HTML elements get produced. Now, when does (server side)
validation need to happen? On the subsequent form submit (the actual
call to invoke the server side validator is one of the things that
RequestProcessor does).
Hmm ..... there's no "tag" there to do the validation for me ....
maybe I need a component model to encapsulate both the rendering and
the validating behavior ... wonder where I can find one of those? :-)
Interestingly, when I read Daniel's post I thought he was advocating adding
validation metadata to the form bean declaration and using dynamic proxies
to generate the beans -- like enhanced Dyna forms. You'd eliminate the need
for a separate validation.xml and, by making the proxy beans smarter so
they could wrap an existing form bean or typed DTO and handle the
string/type conversions in the proxy, you'd get a long way to automating a
lot of the glue code. Sounded like a good idea to me... :-)
Do your comments change if you look at the idea from that direction?
L.
Then you eliminate actionforms as all the validation info is in the form,
and can be automcatically done for you, and then use can use dynamic proxies
to provide properly typed javabeans as output from a form, and use the
models DTOs to put data into forms!
You just described the most common design pattern for using JSF :-).
Daniel.
Craig
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/laurie
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
