Bean tags

[Clóvis Yutaka Harada <cl...@scopus.com.br>]

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

Re: Bean tags

[Ted Husted <hu...@apache.org>]

You might take a look at the Service manager in the contrib folder to
see if that could be used to implement your login service. 

We really can't vote on accepting any change without seeing the working
code. A good deal of the code in the framework came from developers,
like yourself, who implemented a feature and then donated it back.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/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

Re: Bean tags

[ma...@tumbleweed.com]

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