NOT THAT AWESOME.
There have been two things I have found now that are bizarre. Allow me to describe:
1) Let's say that you have a jsp mapped in your struts.xml, and it has an incorrect path somehow. Sure this is your fault, but what would you expect to happen:
A) An error on startup saying that the jsp can't be found?
B) An error when the action tries to forward to the nonexistent jsp?
C) A blank screen (even if the bad jsp call is inside a functioning jsp call by way of s:action?
Now, one would think that A or B would be good, normal ways for an error of this kind to be handled. You web application won't start if you have an invalid action class mapping, so why should it be different for a bad jsp mapping? But, even if we allow startup, (hey, maybe you will put the jsp in there later), shouldn't we throw some sort of error if we forward to a page that doesn't exist?
No, the answer is, C. A blank screen. No messages in the error logs. Awesome.
2) When you have properties on your form that don't map correctly to the variables or setters on your action class, should the framework:
A) Tell you that the action class call failed because the properties couldn't be mapped to an instance variable?
B) Be even more specific and catalog the properties that failed?
C) Tell you:
No result defined for action com.awesometown.SweetAction and result input - action - file: xxxAnd fail without giving you any clue about what happened!
If you answered C, you'd be correct! Odd, but true, you should get an error message that tells you that your property can't map to the action class. What makes this particular situation even stranger is that when you have s:checkbox params that don't map to variables on the action, it warns you. So odd. Ah well. Other than that, Struts 2 is great and I think it's still a big improvement over Struts 1, even if you spend a bit of time banging your head on the wall. At least when you are done, you don't have to code an ActionForm.
Posts
2 comments:
Or this, when it can't find the associated property for a radio tag:
Cannot find bean under name org.apache.struts.taglib.html.BEAN
Bah. I'd call Struts to the devil, but it's too stupid to rise to those Mephistophelean standards.
In response to (2), I would think that a good framework should account for properties which do not map. There are cases in which the names of properties need to be determined at runtime. A good action should recognized unmapped properties and put them somewhere for later use. Just like the old Servlet API would take in any property that came in. So in the case of Struts 2 there should be no errors thrown but graceful adaptation.
Post a Comment