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]
