On Mon, February 14, 2005 12:27 pm, Don Brown said:
As for 2), users can use normal actionforms, _or_ simply define setters on their POJO action class. In the latter case, Struts, behind the scenes, could create a LazyDynaActionForm, and use it to run through validation, then if successful, use it to populate the POJO action. Therefore, in essence, we kept ActionForms, yet made them automatic.
What validation would be performed in such a case? If you are saying create this form on-the-fly just so that Struts can run through the same general procedure, that's reasonable. However, if the point is just to have a class on which we can call a validate() method, wouldn't it be better to just assume that method exists in the POJO Action? Well, not ASSUME it... it would reflectively be checked and if it's there it's called, if not we do the equivalent of assuming no validation failure and continue on.
What I'm getting at is that the above sounds like a bit more work than really needs to be done... If we treat a POJO Action as a bean (we'll assume it still must follow the bean spec), then we can just populate it directly, and call validate() before execute(), assuming it exists. That way people can encapsulate forms with Actions if they want, or keep them separate, completely at their disceretion.
I agree...in theory. In reality, as Hubert pointed out, the type of the property might be integeter, and say the user entered, "one". When validation fails, you want to display the value the user entered, and without the dynabean layer, you can't do that. JSF and Tapestry solve this problem by having the original value stored in the component, then when its validation succeeds, it is set on the backing bean.
Don
Adding to 3), it would be interesting to add "dialog" scope, something Shale is working on for a scope that is for a logic process where multiple instances might exist in a single session (think browser cloning where two of the user's browsers are going through the same workflow).
Here's a possibly more powerful idea... how about the idea of "transactional scope"? Just like in JDBC, the developer would at some point "start" a transaction, say on an initial Action that populates the first page of a wizard flow, then at some point "stops" the transaction, which clears out the objects held in that scope.
The benefit here is that you have something "in between" request and session scope, yet not as narrowly-defined as dialog scope (or, at least it SOUNDS narrowly-defined to me when I hear "dialog scope")
Now that I write this, I see Frank suggested the same "method" attribute. Great minds think alike :)
Or two minds that are WAY off base to the same degree :)
I'll go with your conclusion though!!
Don
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
