Re: StrutsCatalogInputOutputSeparation
Ted Husted wrote: Reasonable minds can disagree. :) No they can't. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StrutsCatalogInputOutputSeparation
I disagree. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] - Original Message - From: Dave Newton [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Thursday, May 12, 2005 10:59 AM Subject: Re: StrutsCatalogInputOutputSeparation Ted Husted wrote: Reasonable minds can disagree. :) No they can't. Dave - 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]
Re: StrutsCatalogInputOutputSeparation
James Mitchell wrote: I disagree. Wait, trinary logic? Dave Is it Friday already? Newton Ted Husted wrote: Reasonable minds can disagree. :) No they can't. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StrutsCatalogInputOutputSeparation
I consider myself a reasonably minded person, yet I tend to disagree with such assertions that, in my mind, are unreasonable. :P -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] - Original Message - From: Dave Newton [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Thursday, May 12, 2005 11:16 AM Subject: Re: StrutsCatalogInputOutputSeparation James Mitchell wrote: I disagree. Wait, trinary logic? Dave Is it Friday already? Newton Ted Husted wrote: Reasonable minds can disagree. :) No they can't. - 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]
Re: StrutsCatalogInputOutputSeparation
James Mitchell wrote: I consider myself a reasonably minded person, yet I tend to disagree with such assertions that, in my mind, are unreasonable. Yeah, but I was being sarcastic. Look, an argument isn't simply a contradiction [...] Yes it is. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StrutsCatalogInputOutputSeparation
On 5/10/05, Benedict, Paul C [EMAIL PROTECTED] wrote: I have read Michael Jouravlev's article: http://wiki.apache.org/struts/StrutsCatalogInputOutputSeparation I can't find any blog or comment box on the page, so I'll write here. I would like people to freely respond to my comments. Apparently, with Moin Moin you need to add any comments directly to the page. We should probably get in the habit of adding a == Comments == section to the foot of each page, since we do want the wiki to be a shared resource. Of course, because it is a shared resource, it's quite possible that some wiki articles will contradict each other in some ways. But, that's OK. Reasonable minds can disagree. :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: StrutsCatalogInputOutputSeparation
Michael, I read your article again two more times, and I have to say I really do like it. It's an ingenious solution; so I am warming up to it in some areas. Regardless, this email thread will certainly help everyone think through the problem :) Here are some further reflections: 1) I wrote: do not like putting any output data in the form unless it started as input. This needs to be framed within the context of normal Struts development. If I am going to return data that will be returned in an HTML form, the appropriate form properties are populated. My sentence is directed towards non-HTML display, what I term output data, because it has no further purpose besides display purposes (i.e.: output). 2) You wrote: Ted Husted does not consider a single forward from one action to another to be chaining ;) Agreed. He explicitly states this when referencing Tiles or a JSP page -- a view needs to be returned. However, my point is virtually moot because the conclusion of your article is not to forward but to redirect. 3) The redirection for errors requires Struts 1.2.7 or later .. or you will lose the error messages. :-) Because redirection creates multiple requests, it does imply that all forms need to become session based. How necessary is this for an entire web application? My general rule is to keep forms in request-scope, because it allows multiple views of a form to be accessed during a session, plus clean-up is automatic. I know your methodology is to associate a random identifier to a session form, but are you concerned that the session can be filled with tons of objects? A malicious user, assuming he knew your methodology, could just F5 the web page and force unlimited memory allocation via the session. Thanks, Paul -Original Message- From: Michael Jouravlev [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 10, 2005 4:51 PM To: Struts Users Mailing List Subject: Re: StrutsCatalogInputOutputSeparation On 5/10/05, Benedict, Paul C [EMAIL PROTECTED] wrote: I have read Michael Jouravlev's article: http://wiki.apache.org/struts/StrutsCatalogInputOutputSeparation I can't find any blog or comment box on the page, so I'll write here. I would like people to freely respond to my comments. I disagree with the two-actions methodology to solve the separation of input and output data. If Actions are a web-interface into your business logic, there is no need to go into another action to do more processing; I believe the chains approach in Struts 1.3 solves this problem by keeping chains of logic below the Web/Struts layer. Perhaps, the wiki page does not have enough arguments and explanation, why I believe this is the good way do Struts UI actions. If you can spare 20 minutes, maybe you would like to read this arcticle: http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost And them check these two applications, they do exactly the same thing, but this one http://www.superinterface.com/fwapp/viewList.do uses in-server forward, and this one http://www.superinterface.com/rdapp/viewList.do uses redirect via browser (sorry, when I was updating the redirecting app, I lost original pages with explanatory text, but the functionality is the same). Try them, try to refresh pages, to go back and forward, to delete item from the list and refresh the list, etc. You will see how robust the redirecting app is comparing to forwarding one. This technique is known as ActionChaining and, as I agree, it seems to be frowned upon: http://wiki.apache.org/struts/ActionChaining Do you think that this technique is bad only because of someone else's opinion? ;) Even King Arthur, Einstein and Von Braun made mistakes. Plese, think it over again, and see i/o separation has its benefits. Also, Ted Husted does not consider a single forward from one action to another to be chaining ;) I personally do not like putting any output data in the form unless it started as input. I envision ActionForms to be tightly linked to HTML forms. I see, this is what I call a DialogAction. I have this too, this is slightly different type of separation, but it is there, too. First, i submit input data to the action using POST, then I redirect to the same action, and load the page using GET. Action decides, is it input or output by request type. Form has session scope. Simple and it works. To clean form I use a special init request parameter. Conceptually speaking, since HTML forms can only contain input-like elements, so should only ActionForm objects too. I put my output data exclusively in request or session attributes as necessary, but never the form; I believe this complicates and misuses the conception of a form. I guess, you use approach like this: http://wiki.apache.org/struts-data/attachments/StrutsCatalogInputOutputSepar ation/attachments/actioncombo03.gif I am totally not against it, I use it myself too. But here you disagree with yourself. You just said, that you do not like putting any output data
Re: StrutsCatalogInputOutputSeparation
On 10/05/2005 21:30, Benedict, Paul C [EMAIL PROTECTED] wrote: I have read Michael Jouravlev's article: http://wiki.apache.org/struts/StrutsCatalogInputOutputSeparation I can't find any blog or comment box on the page, so I'll write here. I would like people to freely respond to my comments. I disagree with the two-actions methodology to solve the separation of input and output data. If Actions are a web-interface into your business logic, there is no need to go into another action to do more processing; I believe the chains approach in Struts 1.3 solves this problem by keeping chains of logic below the Web/Struts layer. This technique is known as ActionChaining and, as I agree, it seems to be frowned upon: http://wiki.apache.org/struts/ActionChaining I personally do not like putting any output data in the form unless it started as input. I envision ActionForms to be tightly linked to HTML forms. Conceptually speaking, since HTML forms can only contain input-like elements, so should only ActionForm objects too. I put my output data exclusively in request or session attributes as necessary, but never the form; I believe this complicates and misuses the conception of a form. I also agree with you. I even created some small package to make my own viewbeans. Pedro Salgado I am ready to be disagreed with... But I want to know why. Thanks, Paul -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp Dohme or MSD and in Japan, as Banyu) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. -- - 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]
Re: StrutsCatalogInputOutputSeparation
Hi Paul, Doesn't putting all of the output data in the session or even in the request add even more clutter and confusion? When the data is nicely packaged in an object you can manipulate it more easily and you can keep track of where the information came from. Although using an ActionForm for this purpose might confuse some, I think that it is a better alternative than putting the data in the session or request scope. Aladin Benedict, Paul C wrote: I have read Michael Jouravlev's article: http://wiki.apache.org/struts/StrutsCatalogInputOutputSeparation I can't find any blog or comment box on the page, so I'll write here. I would like people to freely respond to my comments. I disagree with the two-actions methodology to solve the separation of input and output data. If Actions are a web-interface into your business logic, there is no need to go into another action to do more processing; I believe the chains approach in Struts 1.3 solves this problem by keeping chains of logic below the Web/Struts layer. This technique is known as ActionChaining and, as I agree, it seems to be frowned upon: http://wiki.apache.org/struts/ActionChaining I personally do not like putting any output data in the form unless it started as input. I envision ActionForms to be tightly linked to HTML forms. Conceptually speaking, since HTML forms can only contain input-like elements, so should only ActionForm objects too. I put my output data exclusively in request or session attributes as necessary, but never the form; I believe this complicates and misuses the conception of a form. I am ready to be disagreed with... But I want to know why. Thanks, Paul -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp Dohme or MSD and in Japan, as Banyu) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. -- - 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]
Re: StrutsCatalogInputOutputSeparation
On 10/05/2005 22:21, Aladin Alaily [EMAIL PROTECTED] wrote:
Hi Paul,
Doesn't putting all of the output data in the session or even in the
request add even more clutter and confusion? When the data is nicely
packaged in an object you can manipulate it more easily and you can keep
track of where the information came from. Although using an ActionForm
for this purpose might confuse some, I think that it is a better
alternative than putting the data in the session or request scope.
What about packaging the output data on a java bean and always register it
on a specific name (for example view) either on the request or session
scope?
In the end you have something like ${view.property} on your jsp file.
It is true that you might not be able to easily use html:options but with
JSTL you can reduce this disadvantage.
Pedro Salgado
Aladin
Benedict, Paul C wrote:
I have read Michael Jouravlev's article:
http://wiki.apache.org/struts/StrutsCatalogInputOutputSeparation
I can't find any blog or comment box on the page, so I'll write here. I
would like people to freely respond to my comments.
I disagree with the two-actions methodology to solve the separation of input
and output data. If Actions are a web-interface into your business logic,
there is no need to go into another action to do more processing; I believe
the chains approach in Struts 1.3 solves this problem by keeping chains of
logic below the Web/Struts layer.
This technique is known as ActionChaining and, as I agree, it seems to be
frowned upon:
http://wiki.apache.org/struts/ActionChaining
I personally do not like putting any output data in the form unless it
started as input. I envision ActionForms to be tightly linked to HTML forms.
Conceptually speaking, since HTML forms can only contain input-like
elements, so should only ActionForm objects too. I put my output data
exclusively in request or session attributes as necessary, but never the
form; I believe this complicates and misuses the conception of a form.
I am ready to be disagreed with... But I want to know why.
Thanks,
Paul
-
-
Notice: This e-mail message, together with any attachments, contains
information of Merck Co., Inc. (One Merck Drive, Whitehouse Station, New
Jersey, USA 08889), and/or its affiliates (which may be known outside the
United States as Merck Frosst, Merck Sharp Dohme or MSD and in Japan, as
Banyu) that may be confidential, proprietary copyrighted and/or legally
privileged. It is intended solely for the use of the individual or entity
named on this message. If you are not the intended recipient, and have
received this message in error, please notify us immediately by reply e-mail
and then delete it from your system.
-
-
-
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]
Re: StrutsCatalogInputOutputSeparation
Dave Newton wrote: Isn't that where ActionForms are? In any case, nobody said it couldn't be encapsulated in some nice, tidy object. You're absolutely right. This is exactly what I do. It's just that when Paul said the following: I put my output data exclusively in request or session attributes as necessary, but never the form I took it to mean that he literally puts attribute1-value1 ... attributeN-valueN in the session or the request rather than in an object (like an ActionForm). Aladin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StrutsCatalogInputOutputSeparation
I've read the article now too, and must say i can't disagree more. First: HTML FORM is submitted from the input page, usually using POST request method. Struts populates form bean (marked with [F]) with request data. Then form bean validates input and if something wrong, it generates error messages. If validate() returns errors, Struts does not bother to call action class. Instead, it forwards to location, which is defined in input property of action element. If, on the other hand, input data is correct, Struts calls execute() method of the action class. It usually performs model update, then fills out form bean with output values, and forwards to JSP page, which displays output data. Especially the last one: fills out form bean with output values, and forwards to JSP page, which displays output data Is complete nonsense in my eyes. I've never seen an application doing this. Maybe I haven't seen enough struts applications, but our current application for example, with 1500 classes, 500 jsps, and over 100K lines of code doesn't show this behaviour at a single place. ActionForms are the better way to parse request after form submission. That's it. Nothing less, nothing more. ... Further in text: Form bean is used both for input and for output. If input and output page uses same fields, this is OK, but usually this is not the case. So, one form has to combine input and output fields. See above. I don't think it's struts typical, if it is, again, never seen this before. On error action class is not called. This may be useful in some cases, but not always This depends solely on the validation technique. Actually we are using validate methods of the ActionForm solely to perform javascript validation on the client side (to reduce traffic for client) and to backup it on the server side in case one switched off javascript. What I do validate in Forms are things like length of a specific text field or presence of needed fields. If logic is required, the validation is performed in the action, or even in the service layer. On error control is forwarded to location, defined in input property. This property itself is a source of misunderstanding for Struts newbies, and makes clean request-processing-response sequence a little fuzzy. Typicall for all GUI applications, isn't it? If you don't like it, you can override this behavior. Noone says you MUST use actionforms, struts has enough power without action forms. Because in case of error most applications forward to input page instead of redirecting, page is sent back to broswser immediately in response to POST request. This produces POSTDATA effect on reload, which results in double sumbit. Aehm... The double submit problem is not a problem of POST or GET request. Ist a problem of bad programmed browsers, proxies etc, and there are enough techniques to avoid it. Since your preposition about Traditional Struts request/response cycle isn't TRUE in my eyes, you provide a solution to a problem, that doesn't exists :-) Now seriously. Using ActionForms for result presentation is just a matter of bad style, it doesn't mean, that struts is badstyles, after all, everything, that can be misused, will be :-) Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StrutsCatalogInputOutputSeparation
I've read the article now too, and must say i can't disagree more. First: HTML FORM is submitted from the input page, usually using POST request method. Struts populates form bean (marked with [F]) with request data. Then form bean validates input and if something wrong, it generates error messages. If validate() returns errors, Struts does not bother to call action class. Instead, it forwards to location, which is defined in input property of action element. If, on the other hand, input data is correct, Struts calls execute() method of the action class. It usually performs model update, then fills out form bean with output values, and forwards to JSP page, which displays output data. Especially the last one: fills out form bean with output values, and forwards to JSP page, which displays output data Is complete nonsense in my eyes. I've never seen an application doing this. Maybe I haven't seen enough struts applications, but our current application for example, with 1500 classes, 500 jsps, and over 100K lines of code doesn't show this behaviour at a single place. ActionForms are the better way to parse request after form submission. That's it. Nothing less, nothing more. ... Further in text: Form bean is used both for input and for output. If input and output page uses same fields, this is OK, but usually this is not the case. So, one form has to combine input and output fields. See above. I don't think it's struts typical, if it is, again, never seen this before. On error action class is not called. This may be useful in some cases, but not always This depends solely on the validation technique. Actually we are using validate methods of the ActionForm solely to perform javascript validation on the client side (to reduce traffic for client) and to backup it on the server side in case one switched off javascript. What I do validate in Forms are things like length of a specific text field or presence of needed fields. If logic is required, the validation is performed in the action, or even in the service layer. On error control is forwarded to location, defined in input property. This property itself is a source of misunderstanding for Struts newbies, and makes clean request-processing-response sequence a little fuzzy. Typicall for all GUI applications, isn't it? If you don't like it, you can override this behavior. Noone says you MUST use actionforms, struts has enough power without action forms. Because in case of error most applications forward to input page instead of redirecting, page is sent back to broswser immediately in response to POST request. This produces POSTDATA effect on reload, which results in double sumbit. Aehm... The double submit problem is not a problem of POST or GET request. Ist a problem of bad programmed browsers, proxies etc, and there are enough techniques to avoid it. Since your preposition about Traditional Struts request/response cycle isn't TRUE in my eyes, you provide a solution to a problem, that doesn't exists :-) Now seriously. Using ActionForms for result presentation is just a matter of bad style, it doesn't mean, that struts is badstyles, after all, everything, that can be misused, will be :-) Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StrutsCatalogInputOutputSeparation
One more thing: On 5/10/05, Leon Rosenberg [EMAIL PROTECTED] wrote: Now seriously. Using ActionForms for result presentation is just a matter of bad style, it doesn't mean, that struts is badstyles, after all, everything, that can be misused, will be :-) So, you are saying that using ActionForm for output is a bad style. Depends. Consider this situation (about 80% of this is copied from my reply to Nancy Lin): * There is permanent storage (database) * There is business object, which can be loaded from database. * There is a temporary area in the session (current item) * Current item contains a working copy of persistent business object (along with messages, more on them further). Current item is the one that you are editing or viewing. * There is an action mapping, which does not care, where the data that it shows, comes from. All it knows, that when is receives object ID, it must show object's data. * When [form/action/whoever on that location] receives object ID, it checks current item first. If current item has object with needed ID in it, form uses object's properties. * If object with needed ID is not loaded in current item, then current item is discarded, object is loaded from database into current item and is displayed. * When Cancel is clicked, current item is disposed, database is not affected. * error messages are stored in the current item along with business object, but messages themselves are not part of persistent object. * each time page is reloaded, messages are redisplayed * when changes are reset or canceled, messages are cleared. Now, in my older application I use a separate object to store current item. But if one has only one object on the page, one can as well use form bean as a current item. Form bean scope would be set to session, and it would store error messages, as well as reference to the business object. Also, as you can see, the action which displayes the item, does not accept input of item data. There is a completely separate action for that. editItem action does not care where the data is, and is it new or existing. It just takes ID and pulls the object for presentation. You may consider this bad style, but I think it is convenient. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StrutsCatalogInputOutputSeparation
-Ursprüngliche Nachricht- Von: Michael Jouravlev [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 10. Mai 2005 23:58 An: Struts Users Mailing List Betreff: Re: StrutsCatalogInputOutputSeparation One more thing: On 5/10/05, Leon Rosenberg [EMAIL PROTECTED] wrote: Now seriously. Using ActionForms for result presentation is just a matter of bad style, it doesn't mean, that struts is badstyles, after all, everything, that can be misused, will be :-) So, you are saying that using ActionForm for output is a bad style. Depends. Consider this situation (about 80% of this is copied from my reply to Nancy Lin): * There is permanent storage (database) * There is business object, which can be loaded from database. * There is a temporary area in the session (current item) * Current item contains a working copy of persistent business object (along with messages, more on them further). Current item is the one that you are editing or viewing. * There is an action mapping, which does not care, where the data that it shows, comes from. All it knows, that when is receives object ID, it must show object's data. * When [form/action/whoever on that location] receives object ID, it checks current item first. If current item has object with needed ID in it, form uses object's properties. * If object with needed ID is not loaded in current item, then current item is discarded, object is loaded from database into current item and is displayed. * When Cancel is clicked, current item is disposed, database is not affected. * error messages are stored in the current item along with business object, but messages themselves are not part of persistent object. * each time page is reloaded, messages are redisplayed * when changes are reset or canceled, messages are cleared. Now, in my older application I use a separate object to store current item. But if one has only one object on the page, one can as well use form bean as a current item. Form bean scope would be set to session, and it would store error messages, as well as reference to the business object. Also, as you can see, the action which displayes the item, does not accept input of item data. There is a completely separate action for that. editItem action does not care where the data is, and is it new or existing. It just takes ID and pulls the object for presentation. You may consider this bad style, but I think it is convenient. Hmm, never seen such an object before :-) I mean the object must be _completely_ plain, not one field which is decorated, only 100% the data, the user entered previously? I mean, if you would forget about your object sharing, and create an input and an output object from scratch, the result would be 100% identical? In this case, and only in this case, the above method would be right (in terms of good coding style, etc), but in this case I doubt, that you need an object at all. Since you object is just an encapsulation of properties, without ANY functionality ever, you'd be better served with a set or map of properties. Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StrutsCatalogInputOutputSeparation
-Ursprüngliche Nachricht- Von: Michael Jouravlev [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 10. Mai 2005 23:58 An: Struts Users Mailing List Betreff: Re: StrutsCatalogInputOutputSeparation One more thing: On 5/10/05, Leon Rosenberg [EMAIL PROTECTED] wrote: Now seriously. Using ActionForms for result presentation is just a matter of bad style, it doesn't mean, that struts is badstyles, after all, everything, that can be misused, will be :-) So, you are saying that using ActionForm for output is a bad style. Depends. Consider this situation (about 80% of this is copied from my reply to Nancy Lin): * There is permanent storage (database) * There is business object, which can be loaded from database. * There is a temporary area in the session (current item) * Current item contains a working copy of persistent business object (along with messages, more on them further). Current item is the one that you are editing or viewing. * There is an action mapping, which does not care, where the data that it shows, comes from. All it knows, that when is receives object ID, it must show object's data. * When [form/action/whoever on that location] receives object ID, it checks current item first. If current item has object with needed ID in it, form uses object's properties. * If object with needed ID is not loaded in current item, then current item is discarded, object is loaded from database into current item and is displayed. * When Cancel is clicked, current item is disposed, database is not affected. * error messages are stored in the current item along with business object, but messages themselves are not part of persistent object. * each time page is reloaded, messages are redisplayed * when changes are reset or canceled, messages are cleared. Now, in my older application I use a separate object to store current item. But if one has only one object on the page, one can as well use form bean as a current item. Form bean scope would be set to session, and it would store error messages, as well as reference to the business object. Also, as you can see, the action which displayes the item, does not accept input of item data. There is a completely separate action for that. editItem action does not care where the data is, and is it new or existing. It just takes ID and pulls the object for presentation. You may consider this bad style, but I think it is convenient. Hmm, never seen such an object before :-) I mean the object must be _completely_ plain, not one field which is decorated, only 100% the data, the user entered previously? I mean, if you would forget about your object sharing, and create an input and an output object from scratch, the result would be 100% identical? In this case, and only in this case, the above method would be right (in terms of good coding style, etc), but in this case I doubt, that you need an object at all. Since you object is just an encapsulation of properties, without ANY functionality ever, you'd be better served with a set or map of properties. Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StrutsCatalogInputOutputSeparation
See inline On 5/10/05, Leon Rosenberg [EMAIL PROTECTED] wrote: Aehm... The double submit problem is not a problem of POST or GET request. Ist a problem of bad programmed browsers, proxies etc, and there are enough techniques to avoid it. No. It IS a problem of POST and GET requests. First, the dialog itself. According to HTTP specs, browser is required to display warning dialog, when the same request is re-POST-ed. Ok, you can submit your HTML forms with GET. But this is against HTTP recommendations. Also, it just make the problem invisible to the user, but does not eliminate the problem itself. You would need to use tokens or whatever other technique, to detect double submits. You are right in the way, that I mixed two things in one article: separation of data and separation of processes of input and output. Well maybe I should bring in another example :-) Consider a list of items with a delete function. You will have an action ShowItems which presents the list and DeleteItem which deletes an item from the list based on item's id, which is transmited as parameter to the action, and presents the updated list afterwards. Now, it's clear, that DeleteItem and ShowItems share a lot of functionality on the use case level; the presentation logic of the itemlist. What is often done, and I must admit, that I've done it either, is to let DeleteItem extend ShowItems, performing the delete process in it's execute and calling super.execute then. Does it work? Yes. Is it good? No, because, if a user deletes an item, then someone else creates a new item with the id of the deleted item, and the first user hits refresh, the new item will be deleted unintented. Does it mean that it's a general fault of struts or servlets? I don't think so. As you may have noticed, I did not extend one action with another ;) The grand idea, is that it is not really important, what happens on the server. What important is how this processing is seen from the client. In the case above the developer made a clear mistake from the client perspective: it allowed to repost the delete request. And, if this were a GET request, a user would not even know about it. _This_ is bad design. You can argue, that it's easy to send a redirect to the ShowItems action after the DeleteItem action performed it's task, and you will be right. I just wanted to show, that everything can be misused, but the fact it is, doesn't mean, that _it_ is bad. Like the GET request in the above example. GET request is not bad ;) But not sending redirect in above situation is really really bad. Hmm, never seen such an object before :-) I mean the object must be _completely_ plain, not one field which is decorated, only 100% the data, the user entered previously? I mean, if you would forget about your object sharing, and create an input and an output object from scratch, the result would be 100% identical? In this case, and only in this case, the above method would be right (in terms of good coding style, etc), but in this case I doubt, that you need an object at all. Since you object is just an encapsulation of properties, without ANY functionality ever, you'd be better served with a set or map of properties. I am sorry, I lost in the argument, that we are still talking about input and output form beans. Of course, this object would make better sense as shared, as it currently is shared in my app. Thanks, a reason not to change anything ;) The object is not just encapsulation of properties. The current object (possibly, a form bean) contains business object (with validation methods, what else) and corresponding messages. We can return to this topic later, in about two weeks, when I release my The M in Struts MVC library ;-) Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
