> -----Original Message-----
> From: Paul Benedict [mailto:[EMAIL PROTECTED]
==////==
>
> Frank,
>
> I am fond of these two ideas (see following). Heck, I
> would be willing to even write them if I think there
> would be a chance of someone actually commiting them
> into the Trunk!!
>
> There are four things that I am very fond of and they
> are all tightly integrated:
> (1) POJO for forms
See below
> (2) Stubbing of abstract attributes for framework
> implementation like Tapestry.
Are you talking abouting the ``jwcid'' attribute?
> (3) The use of native data types in forms without
> worrying of validation.
A new validation methodology is required.
With JSF there is processing render life cycle,
now the new version could borrow that model, or
better analyse it and come with something better.
> (4) Action methods being part of the POJO.
Agreed here. I would like the flexible to make the action form
and the action seperate or be part of the same class.
Struts uses the BeanUtil library so in order to change the
use of native types in form without validations may require
changes to that library.
I believe Struts 2 should inject dependencies into the actions
or action forms. It is a little contraversial as there
are many IoC frameworks out to there to do this already.
Struts 2 should force an Action or ActionForm to be interface
or subclass of an abstract type, hence dependency injection.
If the former is the case, then it follows that calling the
action method should be flexible
public void bluegrass(ActionContext ac) { /* ... */}
or
public void bluegrass() {
ActionContext ac = typeOfThreadLocal.getFromSomeWhere();
/* ... */
}
then you need to handle absurdities like so (the general case )
public void bluegrass( A a, B b, ... ActionContext ac, ... Y y, Z z ) { /*
... */}
Also remember we have the chain of responsible stuff and the
Struts action extension to factor, which most developer
haven't even use yet in real anger, into a new version of
Struts 2. Proviso backwards compatibility
>
> Just imagine how cool it would be to have something
> like:
>
> public class MyActionForm {
> // stub out properties
> public abstract String getFirstName();
> public abstract String getLastName();
> public abstract int getAge();
>
> public void save(ActionContext ac) {
> // save form here
> }
>
> public void edit(ActionContext ac) {
> // edit form here
> }
>
> public void bluegrass(ActionContext ac) {
> // do something else here
> }
> }
>
> In this example, all four things happen:
> (1) The object is a POJO and (3) uses native data
> types. If any conversion failure happens, it is
> considered an automatic validation error.
>
> (2) The attributes are stubbed out for implementation
> like done in Tapestry. This allows the type-checking
> at runtime found in ActionForms (important to me) with
> the flexibility of defining forms like DynaActionForms
> (used heavily by me).
>
> (3) Action methods are now part of the action form
> itself. Here I used the Struts 1.3 method of having
> the Chain-of-command object be the only thing passed
> in, which should contain references to any other web
> object you need to complete this request. I believe
> JSF does something similar, and why not imitate this
> good idea? Besides, I think the Struts Roadmap has a
> similar idea planned for 1.5???
>
> Thanks guys.
==////==
--
Peter Pilgrim :: J2EE Software Development
Operations/IT - Credit Suisse First Boston,
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497
==============================================================================
Please access the attached hyperlink for an important electronic communications
disclaimer:
http://www.csfb.com/legal_terms/disclaimer_external_email.shtml
==============================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
