I think the issue is not unique to struts (or jsps). In any complex servlet based web-app you will most likely be performing validation at the server side - even if you use javascript to do basic validation. (For example: while javascript can tell if a user enters a fooID with the correct number of digits it won't know if that fooID is unique in the database - such validation will almost certainly have to be occuring server side.)
In regards to use of session scope, Im having somewhat similar concerns so I will be most interested to see what people say on this topic. My application uses a j2ee b-tier, and there is also a layer of abstraction between my presentation-tier code and this b-tier. From this tier I can obtain value objects (representing BL entities such as say a User Account or some such like). When I display a form in the browser I certainly don't always want to write out every field in my value object (Some contain data I dont want the user to be able to see, or system data, or data that doesnt string-ify well). What I want to be able to do is to hang on to the value obect(s) between the requests (ie: in session scope) and then when the new request arrives from the browser, update the necessary fields, or perhaps look to see if a particular field value was changed and do something, but not do it if that field didn't change (etc...) If I dont put my value object in the session scope, what happens is that I need to look it up again from my b-tier in my post-view action. This is obviously inelegant, and inefficient (as the j2ee server may well be on a different machine to the web server). Furthermore, I may need to go through several different pages (ie: a wizard) to get all the data for something from the user. Again it is neccessary to make use of session scope. BUT if I want to use the session scope there are several issues to consider and I havent yet worked out a suitable solution/compromise for them: 1.) If while editing a FooEntity the user decides to do something else instead, and clicks on one of the many navigational links in the page navigation bar, Ive still got my FooEntity sitting in SessionScope, and it will be there till the user logs out... Bad. 2.) How to avoid confusion with other FooEntities that are being edited in other windows that share the same session? I suppose this would involve storing it under a unique key, (concealed carefully under a hidden field in the html form). This can be used to retrieve the stored FooEntity in the post view action, do the stuff and then remove the stored FooEntity from session scope - BUT how to handle the case where the user created a new window manually and then goes and edits data in this second window having submitted the form in the first. The FooEntity was removed from session scope by the first submission, and so the second will cause an error. -AFTER the user has spend lots of their time editing the data. Bad. The second of these problems isnt so bad, but its the first one that alarms me. How to stop the sessions getting cluttered up with unwanted garbage when the user decides to make use of the provided navigation options instead of 'completing an operation'... Yaman is worried about using too much memory by storing things in session scope. I think we cannot avoiding making use of session scope to keep hold of objects between requests , however the real problem would be knowing when we can safely remove these objects. Relying on them to be removed when the user logs out (or timeouts) seems very inefficient as with lots of users the amount of 'garbage' in session scope could build up quite quickly (esp. if large objects are involved) and put a load on the servers resources - or at least hijack far more of those resources than the presentation tier should have! What to do!!!? -Andrew -----Original Message----- From: Yaman Kumar [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 14:51 To: Struts Users Mailing List Subject: Is Struts architecture a disadvantage? MessageHi, I have a question regarding struts architecture, As the Html form and its validation has been moved and implemented at server side ( a ActionForm ), once any validation error encounters that is shown in the same page from which this request is generated ( this is very impressing), but the page can't retain its old information other than form information. Case: An action class bound data into request scope with 3 different attribute names and forwarding to x.jsp which has got a form (XFORM) too. In x.jsp it received 3 different attributes and shown data in tabular format , when user submits this form to different action this form bean will be validated and if any errors encountered x.jsp page would be shown back to user, at this time user can't see the data that is shown tabular format. As request is new it can't hold the previous state, this compels the struts users to keep this data(3 attributes)in session scope so when user comes back he could see the error with the data too. In a big web application if we keep data in session scope the server/application become heavily loaded. Don't you think this is disadvantage of keeping /validating the formbean at server side. But I'm sure there are more and more advantages over this disadvantage. Please let me know if any better way to solve above problem and forgive me to understand this as a disadvantage of struts architecture. Thanks yaman -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
