Wellie W. Chao wrote:
>I should also add that in my current application, users only have one role
>each, so the multiple <logic:redirect role="xxx"/> tags works as a way to
>display pages based on role. It would not work well if you had multiple
>roles per user. In that case you should do it in the Action class and order
>the {return mapping.findForward("xxx")} statements based on which roles take
>precedence. For example, if a user had both admin and employee roles, maybe
>you display admin, or you could display a different screen that merged
>capabilities/functions from both roles. You can do it in the JSP pages, but
>I think it's putting too much logic into them.
>
>-----Original Message-----
>From: Wellie W. Chao [mailto:[EMAIL PROTECTED]]
>Sent: Friday, April 12, 2002 10:13 PM
>To: Struts Users Mailing List
>Subject: RE: StrutsTiles Design: Model2 and authorization
>
>
>I have my pages separated into directories by role, and I have a shared
>directory called security that provides login, logout, forgot-password,
>register, and other security-related functions. I have the layout tiles and
>common tiles (e.g. nav bars, footers, etc.) protected so that they are
>inaccessible except through a parent tile's RequestDispatcher.
>
>Re: your question about selection of pages based on role, I don't think it
>makes much difference. I would be inclined to do it in the Action, but I
>think you could do it equally well in the JSP page. For instance, I have one
>page that serves as the master welcome/index page for authenticated users.
>Each role (admin, employer, candidate) actually has a different welcome
>page. The way I accomplish this is to have the master JSP page contain three
><logic:redirect role="xxx"/> tags, one for each role, each pointing to a
>different index page.
>
>-----Original Message-----
>From: jfc100 [mailto:[EMAIL PROTECTED]]
>Sent: Friday, April 12, 2002 8:27 AM
>To: Struts-User
>Subject: StrutsTiles Design: Model2 and authorization
>
>
>Hi,
>
>I am attempting to put together a standard run-of-the-mill
>membership-based webapp utilizing Struts/Tiles on tomcat+jboss adhering
>to accepted Model2 design pattern. The site will be acting as a kind of
>portal for both supplier and customer so I am looking to incorporate
>seperating views based on who the user is. (e.g. only a user in the
>supplier group will see links to advert placement functionality).
>
>I have just recently been looking at Tiles and how it can be used to
>assemble the view of the webapp. All this stuff seems to have a lot of
>potential to gel together but I'm not quite there yet so I will try to
>ask as concise a question as possible without confusing myself!.
>
>What is a good way to approach seperating jsp pages from each other
>based on a) functionality and b) user authorization, within struts and
>tiles?
>
>In other words: Is it a good idea to maintain an inheritance tree of
>tiles definitions (xml) and then to maintain a seperate directory tree
>of implementation jsp pages for each user group? This would mean
>possibly that at some point a jsp file would contain tags like
><logic:present role="Customer"> to distinguish between users and forward
>or include content which had been duplicated (into seperate
>'user-template' directories) but tailored for each user group which was
>allowed access to that piece of functionality?
>
>I can see that in terms of functionality that the action mapping's
>forward must know which page to select based on functionality. Should
>the Action servlet select a particular forward based on who the user is
>too or should this be left to the utilization of tags in the jsp
>pages/templates?
>
>One of the resources (the struts design tips catalog) mentions that the
>view should be pretty but stupid. What bearing does this have on the
>above questions?
>
>Thanks
>Joe
>
>
>--
>To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>
>
>
>--
>To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
hmmm, interesting. It seems that a certain amount of duplication is
inevitable and that the trick may be find a balance between complexity
and duplication of effort with which you are happy.
I find the idea of setting this up (with an eye to adaptability and
maintaining that seperation of roles between designer and developer) to
be quite a challenge.
Cheers
Joe
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
