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
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" 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 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 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" 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
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]
StrutsCatalogInputOutputSeparation continued / PRG
Michael, I want to continue this discussion because I think it has merit. I've used the PRG pattern for over a year since I first came across your article on TheServerSide.com. It works well in most cases, but I don't use it 100% of the time because of certain limitations. It just happened that your positing to the Struts Wiki brought up this subject again, and, to me, and it's worth revisiting. I only implement PRG on hard operations (such as saving or deleting, as opposed to viewing) that succeed. Redirecting after a successful operation that concretely alters data is critical to prevent the POSTDATA situation. However, I do *not* implement PRG on loading an item for viewing/editing or a failed save/delete. I deviate from your recommendation because (1) I want to keep automatic Struts validation and (2) I do not want to put errors and messages in the session. Can you give me some strong arguments to why I should yield from my preference? I want to see the benefit. As a general rule, my forms are request scope because I do not want to tie a user's view to their session. For instance, I've seen clients who CTRL+N in Internet Explorer and surf around a web application in two separate views -- what makes this special is that IE allows different views (windows) to be under the same session!! By altering the app in one window, the other window could be adversely affected on its next request. So, for instance, could your recommendation allow editing of two simultaneous WhateverForm items within the same session? This is an important requirement that I cannot lose. 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]
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/action
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
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]
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]
AW: StrutsCatalogInputOutputSeparation
> > 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. 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. > > 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 :-) > > I would love your version of "Traditional Struts > request/response cycle". I guess, it is the one where all > output is put into a separate bean, not related to form bean. > Is it traditional? Then who taught me to use form beans for > output? I must have read it somewhere :) I am not really fond > of this too. This is in part how I came with the idea of two > forms. Anyway, I guess this "traditional" cycle was my own > premise based on the fact that action mapping contains > "name". Seems, that everyone uses form bean for input only. > Official Struts users guide does not exactly endorse any > specific method of where to put output data, as I can see. or does it? I don't know it to be true, it's just what my mind told me to do, as I learned it. In fact I started using struts with action mappings and taglibs only, and was parsing the form input by myself (some abstraction layer on request.getParameter), so it was all natural to me to use output beans, because i wasn't using any action forms at this moment. > > I will update wiki page. Thanks for comments! :-) Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: StrutsCatalogInputOutputSeparation
> > 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. 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. > > 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 :-) > > I would love your version of "Traditional Struts > request/response cycle". I guess, it is the one where all > output is put into a separate bean, not related to form bean. > Is it traditional? Then who taught me to use form beans for > output? I must have read it somewhere :) I am not really fond > of this too. This is in part how I came with the idea of two > forms. Anyway, I guess this "traditional" cycle was my own > premise based on the fact that action mapping contains > "name". Seems, that everyone uses form bean for input only. > Official Struts users guide does not exactly endorse any > specific method of where to put output data, as I can see. or does it? I don't know it to be true, it's just what my mind told me to do, as I learned it. In fact I started using struts with action mappings and taglibs only, and was parsing the form input by myself (some abstraction layer on request.getParameter), so it was all natural to me to use output beans, because i wasn't using any action forms at this moment. > > I will update wiki page. Thanks for comments! :-) 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
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 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 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
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/StrutsCatalogInputOutputSeparation/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 in the form unless it started as input". So, you _can_ use the same form for input and output? This is just a matter of particular situation. But I agree with you, that ActionForm is probably not the best place to put output data. On the other hand, if I have a business object or DTO, and a reference to this DTO in the form, this would work too, would not it? > I am ready to be disagreed with... But I want to know why. Umm... I think I need to split the wiki page into two, or something. There are two aspects: * First, is how to separate data itself. * Second, how to separate the _processes_ of input and output. The second is important in order to provide better user experience and to allow a user to click Refresh, Back and Forward wherever he likes, and not to produce POSTDATA situations and double submits. As a user I hate POSTDATA dialogs, they make me want to reach out for a shotgun (but I do not have a shotgun). As a developer I hate to process double submits and to handle tokens. POST->redirect->GET solves both my problems as a user and as a developer problems. Roundtrip? I do not care about roundtrip. There are additional benefits of redirection like having a single URL for GET. You can POST whatever data you like, but if you redirect after your POST, and pull the page using GET, browser would use only the GET location to include in session history. And if your GET location is always the same, the session history will not grow. Check out this link: http://www.superinterface.com/rdapp/viewList.do Click "edit", try to enter some non-integer stuff. Do it several times. Try to reload, see, no POSTDATA. Then click Back, see that you return to the list _immediately_. You do not need to click Back as many times, as many times you entered wrong data. This is
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
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 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
Aladin Alaily wrote: 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. Isn't that where ActionForms are? In any case, nobody said it couldn't be encapsulated in some nice, tidy object. One project I saw had "output" data in ActionForms: hit a page, the ActionForm is loaded (for instance, with a list of headlines, etc.) by Struts then used on the page as an output object. I was opposed, although it was nice that it was magickally instantiated and the logic was completely removed from the Action. However, everything was tied to Struts and I couldn't reuse functionality in non-Struts code. I think whether or not ActionForms are input or output could be argued either way. Even the Struts page says: *"Note:* While ActionForm beans often have properties that correspond to properties in your Model beans, the form beans themselves should be considered a Controller component. As such, they are able to transfer data between the Model and View layers." That said, I've never (and most likely never will) put data into an ActionForm that isn't destined for an HTML form: I like the _concept_ of putting "output" in ActionForms but think that ActionForms are best reserved for HTML forms. Output data belongs elsewhere, preferably in a nice automagically-instantiated ActionForm analogue, decoupled from Struts. Dave
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 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]
StrutsCatalogInputOutputSeparation
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]
