The second article of the Redirect After Post series on TheServerSide contains two terrifically bad design choices. On creating an item: Note: createItem was originally invoked using pushbutton and POST method. But Struts throws an exception if an action corresponding to HTML FORM does not define a form bean. Because createItem action does not use form beans, the HTML FORM had to be changed to a link. Thus, createItem is now called using GET method. On deleting an item: deleteItem action removes an item from persistent storage. It receives item ID from the link on viewList.jsp page. Updating model in response to GET request is against semantics of GET method, but I decided to keep it that way. While the purpose of the article is to demonstrate a technique to avoid double submits from a browser and not neccessarily appropriate application design, using GET to obtain a side effect is fundamentally bad practice. It's difficult to imagine an article about Java that would pass technical muster if the author decided to publish deliberately bad code, for example, swallowing exceptions. The technique itself works, but is of limited use - among other things, it appears to depend on a bug in the Internet Explorer web browser. There are more direct ways to solve the problem. In fairness to the author, the problem he's tackling is a real one. And taking the articles together, it's not unreasonable to conclude that the forest is being hidden by the trees insofar as the details and nature of the web framework is affecting an ability to produce a decent application. Making a web framework architecture fundamentally reliant on state when the underpinning application protocol is stateless seems to put developers in the awkward position of making bad design choices in order avoid dissonance with the framework. Hiding statelessness in a web system appears to be a design guff on a par with that of long running transactions, network transparency or synchronous RPC. Most Java frameworks are based on the Model View Control pattern, but articles such as this one suggest the pattern is out of context on the Web. More recent frameworks, such as WebWork and Jave Server Faces attempt to elide the details of HTTP from developers even further, which may be storing up trouble for the future....
Previous Topic
