[prev in list] [next in list] [prev in thread] [next in thread] 

List:       struts-dev
Subject:    RE: Bean tags
From:       "Nicholas Lesiecki" <nick () eblox ! com>
Date:       2001-10-23 16:09:18
[Download RAW message or body]

If you're using 2.3, Servlet Filters provide a handy way to tack logon
functionality onto an easily configurable set of URL mappings, including
Struts Actions. Unless you can't use 2.3 for some reason, this is an option
well worth investigating.

Let me know if you'd lilke to see some sample code.

Cheers,

Nick

-----Original Message-----
From: Clóvis Yutaka Harada [mailto:clovis@scopus.com.br]
Sent: Monday, October 22, 2001 3:48 PM
To: struts-dev@jakarta.apache.org
Subject: RE: Bean tags


Adding a new layer in Action is a good idea. I can create a BaseAction and
make perform() a final method (or not) which calls a doPerform() or
something else in subclasses.
But I cannot use the 'parameter' attribute. This is a standard facility I
want to leave to the Action developer. And there are already lots of
applications using this facility.
Custom action mapping works but I think that it is not an elegant solution.
The developer will have to duplicate all action entries because of a single
property and it can become a maintainance problem.


-----Original Message-----
From: martin.cooper@tumbleweed.com [mailto:martin.cooper@tumbleweed.com]
Sent: Tuesday, October 16, 2001 3:02 PM
To: struts-dev@jakarta.apache.org
Subject: Re: Bean tags


In Struts, you could make your ControllerExtension a subclass of Action,
and override the perform() method to do your login checking where
necessary, before passing control to your main execution method. The
configuration could be done using the 'parameter' attribute of the action
mapping, or by using custom properties on a custom action mapping.

--
Martin.


At 05:31 PM 10/15/01, Clóvis Yutaka Harada wrote:
>Hi,
>
>I´m new to this list and also new to struts.
>
>I was working on my own framework for j2ee application. And I noticed that
>it is very similar to struts.
>The major exceptions are :
>- struts has much more custom tags
>- struts has many contributed tools and libs (console, tiles, camino, ...)
>- struts leaves all logon control to the developer of the actions
>
>I´m working for a real project that will use this structure and I decided
to
>forget my framework and start using struts.
>The reason seems obvious: I can´t compete with struts team :-). And I
>believe struts will continue to evolve for a long time.
>
>But there´s some features that I think is missing in struts and I will put
>in the my copy of struts (release 1.0).
>Since these changes are simple I think they were not implemented because of
>the absence of someone interested in the features.
>
>Since I already had coded the features on my framework I think it won´t
take
>too long to implement them in struts.
>
>If there is some interest to any of these changes let me know.
>
>1. Accept a Map anywhere a Bean is required
>    A Map is very similar to a Bean. Instead of setter and getter methods,
a
>Map has a put and a get methods.
>    Sometimes I don´t want to create a bean only to pass some information
to
>a jsp view, if I already have the information on a Hashtable for example.
>Using maps developers of diferent layers or tiers can code independently
>without even exchanging a bit.
>
>2. My Iterate tag works in collaboration with two nested tags "index" and
>"key".
>    Sometimes I want to put index number on an table list and "index" tag
>shows the actual iterate cicle. "index" starts at 1 by default but can be
>configured with the "startIndexAt" iterate optional attribute.
>    "key" is similar to "index" except when the iteration is over a Map. In
>this case "key" shows the actual key of the Map.
>
>
>3. Logon control
>    In my framework an Action is called ControllerExtension and is
configured
>in a xml file (read by the ControllerServlet - like struts) but it has an
>additional parameter "login" with one attribute "required" that defaults to
>"true". If login is required for a requested extension, the
>ControllerServlet calls a configured extension that returns null if the
user
>is not logged in and the controller redirects the request to the configured
>login form jsp or whatever is configured. If the user is logged in then the
>extension returns a User object (User is an interface defined by the
>framework) which is passed to the requested extension.
>     Doing so I believe I keep authentication logic confined in few
classes.
>
>
>The critical change here is 3. logon control. It changes the structure of
>struts.
>If the change is not accepted by you I will have to study other way to do
it
>or I will have to live with a custom version of struts and have to hack all
>upcoming versions to work with my extensions (Actions).
>
>I think there is a good reason for struts not dealing with logon. If there
>is something that I am missing in my approach I will be glad to know.
>
>
>
>Clovis

[prev in list] [next in list] [prev in thread] [next in thread]