At 05:46 PM 2/15/01 -0200, Rogério Saran wrote:
>Struts could handle this situation by itself with some "action chaining"
>construct, like declararing "action filters" or "roles" on the
>struts-config action tag. The former is a generic approach to handle
>"ok, you want this action to be performed but... first we will do some
>check on model state to see if it is valid". The second is a direct
>approach to solve the authentication problem. Struts would carry a role
>setting for each user session and actions would be screened by these
>roles. This is not a formbean-based screening, but a model-based.
What we do is subclass ActionServlet and override a couple of methods to
perform an authentication check before going ahead with the action itself.
I think this is a fairly common approach with Struts today.
On the subject of roles, you may be interested to know that there is an
item on the Struts 1.1 ToDo list entitled "Role-Based Action Execution".
>A suggestion is to provide mechanics to define all "hard" forwards (real
>URLs) on the global forwards section, and refer it on "set-properties"
>for each action definition. This way the path and name of the views
>would be set only once in the application. Nobody needs to know the
>application is showing "/jsp/index.jsp?skin=default" (the logical
>forward destination). They just want to see "indexpage" (a logical
>forward), and this is result of "home.do" or "login.do" (action
>mappings). Only those actions should "see" these forwards, and an
>explicit declaration on struts-config would improve the implementation,
>ensuring good design.
I'm not sure I understand this completely, but let me see. I think you are
suggesting that all forwards are defined as global forwards, and that each
action declare the list of forwards (by name only) that it uses. Are you
also suggesting that this list be a constraint on the action? That is, an
action can use *only* the forwards listed in its section of struts-config?
You could, of course, partially achieve this with Struts today by always
using global forwards, and using comments to document which ones are
invoked from each action. This obviously won't handle enforcement, though.
Personally, I wouldn't want to go this way. I prefer to make use of local
forwards because it increases locality. All the information for an action
is encapsulated in that one <action> section of struts-config. I know that
the forwards defined there can't be invoked from any other action, which is
something I cannot tell if all forwards are global.
>What troubled us is the suggestion on the sample application to add tags
>handling controller or model logic. The "app:checkLogon" definitely is
>not handling viewing tasks. It checks the "model" for authentication,
>then do "controller" tasks redirecting the user to another page. This is
>a patch for non-mvc behaviour, where the "action" is a direct reference
>to the JSP and the "control" is a bunch of code hidden on tags. If
>somebody forget a tag it is broken. You also cannot use static content
>because your "view" should be able to do controller processing.
>
>The origin for this "design flaw" is lack of controller support when the
>user requests a JSP document directly.
I agree this is ugly, although it's not really a Struts issue so much as a
Servlets 2.2 issue, as I understand it. Unfortunately, I don't know of a
good solution. Filters in Servlets 2.3 might provide a way, though.
--
Martin Cooper
Tumbleweed Communications
