Rick Reumann wrote:
Bill Siggelkow wrote:
Good point, Rick. Isn't this the sort of thing that JSF allows?
Not sure haven't looked at JSF yet:) Plan to at some point. Craig?
Of course, you can bind a validation to an action mapping using the
ValidatorActionForm -- however this still forces your b
Bill Siggelkow wrote:
Good point, Rick. Isn't this the sort of thing that JSF allows?
Not sure haven't looked at JSF yet:) Plan to at some point. Craig?
Of course, you can bind a validation to an action mapping using the
ValidatorActionForm -- however this still forces your business objects
to e
Good point, Rick. Isn't this the sort of thing that JSF allows? Of
course, you can bind a validation to an action mapping using the
ValidatorActionForm -- however this still forces your business objects
to extend this form and it doesn't solve the populate problem.
As far as the problem of migr
Bill Siggelkow wrote:
I would concur with Ted -- I have worked with Struts apps that take
approach (B) -- that is, using the business object as the Form -- not
only does this bind your business object to the Struts API -- more
importantly, you have to make sure that all the field types are strin
I would concur with Ted -- I have worked with Struts apps that take
approach (B) -- that is, using the business object as the Form -- not
only does this bind your business object to the Struts API -- more
importantly, you have to make sure that all the field types are strings
or booleans. If no
For a large, heavy-duty-input data-driven web application, I would recommend C.
> C) [Conventional class] is NOT used, data form validation is defined within the
> validation.xml and handled by struts, the Action class (or some
> surrogate) then enforces all business rules.
I've had deep discuss
6 matches
Mail list logo
