« Execute this: managing configuration in programming languages | Main | Why Lisp will be around for another 50 years »

502 Bad MVC Framework

[updated: Michael Jouravlev, the author of the articles was kind enough to propose a fix via a comment. I'll amend this entry more thoroughly to reflect that later.]

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. 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 it seems he is aware of the issues. Yet 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 or changing object state as a result of calling a getter.

Taking the two 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 uncomfortable position of making bad design choices in order to 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.


November 4, 2004 09:58 PM

Comments

Danny
(November 5, 2004 11:24 AM #)

MVC does generally work pretty well for Java objects, so how (in general) do you square the circle here?

I don't know, but I wonder if there is actually anything fundamentally wrong in practice or principle with layering statefulness on top of a stateless protocol, in a similar way to sync done over async (or the other way around..?)

(I agree entirely about the misuse of GET etc).

Bill de hra
(November 6, 2004 05:35 PM #)

"I don't know, but I wonder if there is actually anything fundamentally wrong in practice or principle with layering statefulness on top of a stateless protocol, in a similar way to sync done over async (or the other way around..?)"

In principle no. In reality there can be problems when you try and pretend such things are not the case (hence my mention of other issues that this reminds me of). I'm still not sure whether the problem is as general as state over stateless, or is highly specific to the (mis)application of MVC in a number of Java frameworks, the post is a bit garbled as a result.

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1426