Pankaj Dhoolia wrote:
Folks,I assume your controler would decide what deefinition to forward. Also... each tile would have a controller.
Was experimenting with patterns to componentize presentations.
Found Tiles absolutely well suited with its concept of Controller per
tile.
But I realize that populating the tile maynot be the only thing that I
want to, one may want to do more things which are generic in nature
rather than being Tile specific. For example, a common requirement is to
display or hide, on the basis of the context of the request (and that
may be more than just principal and role). There may be many such
requirements which I may want to dynamically want to plug on in a
generic manner to a selection of my tiles.
An ideal way probably would have been to have the ability to define a
set of controllers in a particular sequence for a Tile along with the
Tile definitions, but since there is an option for only one, I probably
need to work my way around.
So here's a thought broken down into a number of points:
* Let me define a single generic Controller
* Along with it define my own configuration schema where in I can
define a mapping of my presentation components to the set (and sequence
of the controllers that should be executed before the presentation is
made). Of course I can cache it and take care of dynamic changes to this
cache at runtime etc (if I need to)
I assume you will use standard servelt 2.2 based declerative security for starters and build on it. Web.xml and Struts config support this.
* Now let me define a generic Security Controller for my site
which encapsulates the understanding of the implementation of security
policies on my site.
Ex: if usersinrole().
Read up n jdbc relms (and struts.config in StrutsInAction bu Husted)
Security is handled by cotainer/framework. But lets assume you did a base action and now you write concreate actions.
* Along with this generic Security Controller now I define a
schema where I can define a mapping of my presentation components to the
associated security rules. Of course I can cache it as well along with
taking care of dynamic changes to this cache at runtime etc (if I need
to)
* Now when every Component is to be displayed my generic
Controller (not the generic security controller) is invoked which looks
at the sequence of controllers to be executed and coordinates the
display, and if my generic security controller is also to sequenced then
it is just brought into picture by the generic controller and it
utilizes the ComponentContext and the security mappings configurations
to execute what ever security rules its wants to.
IT IS A BAD PARCTICE NOT TO USE STANDARD SERVLET 2.2 DECLERATIVE SECURITY. Start with it and build on top of it.
That is my .02 cents.
.V
Just wanted to have your opinions on the model, and if there are
alternative models that have been tried for similar scenarios (I believe
the scenario is a very common scenario).
Of course I know it for a fact that Action PlugIn extension by ASQdotCOM
can also be be utilized for such a need
cheers,
pdhoolia
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
