On 15 Feb 2004, at 23:43, Michael McGrady wrote:
You [Mark Lowe] said:
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.
If you have a complex view which needs to be dynamic in nature, I am merely saying the solution is not to build a mammoth ActionForm and save it into session. That is a blunt instrument, in my opinion, that will do nothing but misuse space and cpu cycles. That also is, in my opinion, and in the opinion of many much more developed in this area than myself, somewhat contrary to the idea of using an MVC architecture as applied to the web environment.
Perhaps HttpSession is a blunt instrument, and would need to be substituted by another persistence mechanism like say writing to a temporary text file, but IMO this would be something that one would want to fix in the case that something were broken. And implementing an alternative persistence mechanism personally and perhaps more elegant. I cant help thinking however that HttpSession is there and at least during the development cycle should be used, if found to use too many resources then sure find a way optimizing it.
But during the initial stages of development I'm not convinced that concern about cpu cycles and space is what one should be overly concerned with. i know its a naive position but I thought part of the scope of the java language was in part an attempt to abstract software development from the hardware.
What you need, if you have a need for a dynamic form, i.e. one that needs to have hidden fields generated depending on which page you came from (and that is the hypothetical situation you asked us to address), then you need a dynamic form. You are merely assuming that the page should be WRITTEN with hidden fields instead of being GENERATED with hidden fields. If you have a well-thought out architecture, you should be able to GENERATE the hidden fields you need on the fly. Then, anyone who knows the architecture, and (what is the same) what is really going on, will not be befuddled. You cannot have page writers actually write dynamic forms. They can write the forms as a template, but they would have to be generated by the application, if you have any kind of sophisticated view arrangement.
Okay agreed that generating hidden fields would be a reasonable means of persistence. Yes I was assuming, perhaps in error, that what was being suggested was writing hidden fields. In fact I think I may do this. Also agreed that if the webforms dont have a load of
<html:hidden property="someUnrelatedProperty" />
in the jsp then fine and dandy.
I don't know why we are so slow to develop sophisticated logics for views. That seems to be the last thing on the agenda. I guess that is not entirely true, given Tiles, etc., but it sure is widely true.
Michael McGrady
P.S. I noted the use of i18n because that is a use of the session that makes sense to me.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
