Hubert Rabago wrote:
That would only get you an object to hold values, right? You'd still
need to put validation rules somewhere. With an ActionForm, its
validate() method should contain this. Of course, it could delegate
it somewhere, but you'd be maintaining that, instead.
I assume you mean user input validation . . . Don't you have to do that no matter what type of form you are using (again I'm showing my inexperience with Dyna forms)? I was thinking of auto-generating a ValidatorActionForm subclass (sorry I said ActionForm).
This also would reduce ActionForm reuse, though I don't know if reuse
happens often enough to stop the committers from adopting a good
alternative.
As long as the ActionForms are generated and regenerated for you, do you miss the lack of reuse? It might lead to longer build times, but of course conditionals can be set up.
Hope you don't mind me saying this, but IMO it could be an alternative to DynaActionForms. In fact they sound similar - the form gets generated, the validation gets delegated. You'd need a way to specify initial values, too.
Hmm, why would I mind you saying that? Yes I was thinking of something similar to DynaActionForm, but instead of using Maps and reading the config file, it would use type-safe beans and actually read the forms themselves . . .
Erik
On Mon, 21 Feb 2005 12:16:01 -0500, Erik Weber <[EMAIL PROTECTED]> wrote:
First, let me say that I understand how Dyna forms work, but I don't use them. If I'm way off here or suggesting something that isn't possible, or already has been done, take it easy on me. :)
I was suggesting that perhaps a parser could read a JSP that contains <html:form>, and treat that form as a document. The parser handler could generate a Java source file (regular ActionForm subclass) with fields based on the form input types and with accessors/mutators. Seemingly even complex nesting could be handled once the parser handler evolved enough, by generating collection fields instead of simple fields. This generation could then happen at build time.
Erik
Hubert Rabago wrote:
Can you elaborate? Do you mean a utility that would parse incoming form values and then map them to my business objects? :)
On Mon, 21 Feb 2005 11:48:33 -0500, Erik Weber <[EMAIL PROTECTED]> wrote:
I didn't mean "better than either one". I meant "better than building your own ActionForm by hand", and thus better than using Dyna form.
Erik
Erik Weber wrote:
Wouldn't a parser handler that could build an ActionForm skeleton during a parse of a form JSP be better than either one?
Erik
Hubert Rabago wrote:
I really would not give too much weight to the blog you linked to. If you've read the comments of the readers, you'd see that some of his arguments aren't really that strong, and some are even totally incorrect.
Personally, I use DynaActionForm for each form that it can support. Once I have a form with needs that a DynaActionForm can't fulfill, that's when I decide to use ActionForms. I've had apps where I had more ActionForm subclasses than DynaActionForm, and this was due to requirements that DynaActionForms simply couldn't handle. Still, my first choice would be a DynaActionForm when possible. Pre 1.1, I've had an app where it was form bean after form bean after form bean. I got tired of it that for some forms, I just used plain HTML without Struts tags/form beans. I don't want to go back to that again.
Maybe I shouldn't say anything since I haven't done any JSF yet, but solely from my impressions of what I've read so far: I think the concept of JSF's backing beans are different from Struts' ActionForms. I think JSF's overall approach is different from Struts, that the differences are greater than the similarities. Whether ActionForms or DynaActionForms is more similar to JSF's backing beans shouldn't affect your decision, since you're using Struts, not JSF. Applying the models of one framework to another when their approaches and principles, as well as their underlying support, are different, just sounds dangerous.
As for compile time type information, well, Strings are Strings whether you use one or the other.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
