On 15 Feb 2004, at 14:02, Michael McGrady wrote:
At 04:20 AM 2/15/2004, you wrote: You Said:During a payment process one may want to collect various details about a user, likewise in other parts of a system you perhaps want to do the same albeit in a different order. Hiding form values from a previous view would lock you into always needing to having the first form precede the second.
First, this is not true. You are not locked into anything. All this means is that you have to think about and plan for the actual logic you are coding to in the view. Having hidden fields does not mean those fields have to be initialized or even to exist. Indeed, you can condition the presence of the hidden fields on the order of the conduct of the session. I like a view to dynamically reflect what the logic of presentation is. This is, e.g., the point of i18n. We can profitably keep the locale of the user in session because this value in fact is a session attribute.
Having additional fields that may not related to the given form I'd say at least would confuse a site builder who comes along and has to work out what's going on. For example a bunch of user details in a credit card form would (IMO) cause a whole bunch of problems in determining what the form is for. Simply taking the form and sticking in another webapp would be messier.
So you have an address form for an order and you want to use this form in a profile edit view and during an order process. But the form could now have a bunch of hidden values in there and I'd certainly find this confusing if i was coming in cold to do the site build.
I don't see how this related to internationalization.
Although scoping the form its self in the session may not be the best option surely storing the values collected in the session would be more desirable as your forms remain clean and not dependent on and preceding forms.
Second, this does not meet what I would call a "clean" design. What we respectively think is "clean" depends, I think, on other priorities we have. I like to use the ActionForm strictly in relation to a view. Forms should reflect the logic of the view in my opinion, rather than be a sort of replacement technique on a temporary basis for the database in the model. Whether I am right in being so dogmatic on this is another issue.
But thats what I'm saying the action forms are coupled the view and not to one sequence where say a wizard interface is used. The form can be used elsewhere , in a different manner. I don't see this as a temporary data base, but as a structure to store data collected until the user is certain s/he wants to commit to the database/place are order, send a mail whatever. Its true that this needn't be stored in HttpSession but I'd certainly say that session is a very convenient means of doing so.
A component could have a jsp, an action form and an action and have minimal reference to other actionforms, actions and jsp's. The only glue between each component during a process like the one I'm describing would be he object stored in the session, if the glue is described as a form-bean in struts-config then all the better in terms of not having to write too much documentation to explain what's going on.
Its clean in terms of the web-tier can be developed, forms validated and the only place where this data is passed up to the model. Clean also in that each form maintains some meaning in itself as there are no hidden fields that may not related directly to the form in question.
Opinions are always good especially dogmatic ones, least I hope so else I'm fucked :o)
--------------------------------------------------------------------- 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]
