RE: [OT] Newbie Design best practice question
You might consider writing custom tags of the form custom:fulluser functionality for full user /custom:fulluser etc. This would keep the jsp simple but allow you to localize the functionality. Edgar -Original Message- From: Piper, James D CECOM SEC EPS [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 17, 2002 2:05 PM To: [EMAIL PROTECTED] Subject: [OT] Newbie Design best practice question If I were to have a STRUTS enabled application where I had user types of restricted_users, full_access_users, and admins and for the most part the content of the screens the different user types get to see are the same, except for maybe Id like there to be a few extra bits of functionality on the full_access_users and admin screens that doesn't get shown on the restricted_users screen, then what's the best way to go about this? It will probably also be that each user type will require some Action objects not used by the other user types. Should I attempt to use one set of JSPs for all the different types of users and put logic inside each of the JSPs that says something like 'if the user is of type full_access_users then shown these extra few buttons', or should I give each type of user their own set of JSPs? I am tempted to try and use one set of JSPs for all user types so that I don't have to worry about maintenance of three sets of almost identical JSP files. On the other hand I feel I may be asking for security trouble by trying to have each JSP check for the user's user type - I also have a notion that checking user types is something that I should be doing elsewhere. If I do use separate JSPs for each user type, would it make sense to use the STRUTS sub-application mechanism to separate them out? Thanks for your thoughts, - Jim -- 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]
Re: [OT] Newbie Design best practice question
I would use 1 jsp for all groups with a custom tag to check if the user is in a given role: yourtags:checkIsInRole role=admin admin content here /yourtags:checkIsInRole Dave From: Piper, James D CECOM SEC EPS [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [OT] Newbie Design best practice question Date: Tue, 17 Sep 2002 14:05:29 -0400 If I were to have a STRUTS enabled application where I had user types of restricted_users, full_access_users, and admins and for the most part the content of the screens the different user types get to see are the same, except for maybe Id like there to be a few extra bits of functionality on the full_access_users and admin screens that doesn't get shown on the restricted_users screen, then what's the best way to go about this? It will probably also be that each user type will require some Action objects not used by the other user types. Should I attempt to use one set of JSPs for all the different types of users and put logic inside each of the JSPs that says something like 'if the user is of type full_access_users then shown these extra few buttons', or should I give each type of user their own set of JSPs? I am tempted to try and use one set of JSPs for all user types so that I don't have to worry about maintenance of three sets of almost identical JSP files. On the other hand I feel I may be asking for security trouble by trying to have each JSP check for the user's user type - I also have a notion that checking user types is something that I should be doing elsewhere. If I do use separate JSPs for each user type, would it make sense to use the STRUTS sub-application mechanism to separate them out? Thanks for your thoughts, - Jim -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [OT] Newbie Design best practice question
We just went through similar agony with four levels of users. We ended up with two sets of JSP pages. We ended up doing a second set for one of the groups because there was just so much of a difference and it would be helpful to have a different layout. Of course we are still working on it so I cant say it all worked out for us :) -Original Message- From: James.Piper [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 17, 2002 2:05 PM To: struts-user Subject: [OT] Newbie Design best practice question If I were to have a STRUTS enabled application where I had user types of restricted_users, full_access_users, and admins and for the most part the content of the screens the different user types get to see are the same, except for maybe Id like there to be a few extra bits of functionality on the full_access_users and admin screens that doesn't get shown on the restricted_users screen, then what's the best way to go about this? It will probably also be that each user type will require some Action objects not used by the other user types. Should I attempt to use one set of JSPs for all the different types of users and put logic inside each of the JSPs that says something like 'if the user is of type full_access_users then shown these extra few buttons', or should I give each type of user their own set of JSPs? I am tempted to try and use one set of JSPs for all user types so that I don't have to worry about maintenance of three sets of almost identical JSP files. On the other hand I feel I may be asking for security trouble by trying to have each JSP check for the user's user type - I also have a notion that checking user types is something that I should be doing elsewhere. If I do use separate JSPs for each user type, would it make sense to use the STRUTS sub-application mechanism to separate them out? Thanks for your thoughts, - Jim -- 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]
RE: [OT] Newbie Design best practice question
Tiles can also help you separate JSPs by role--all you need to do is provide your own definition factory. In my current app, I created a definition factory to take the user's role into account. Then in my struts-config, I just forward to, say, template.home and Tiles does all the hard work of deciding which definition should be used. You can still have common elements, too (login, logout, headers, etc). That scheme helped us keep the JSPs a little cleaner than they would be otherwise (with giant blobs of foo:isRole name=admin.../foo:isRole all over the place) and also helped with organization and separation (so different teams could more easily focus on different roles). chris -Original Message- From: Piper, James D CECOM SEC EPS [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 17, 2002 1:05 PM To: [EMAIL PROTECTED] Subject: [OT] Newbie Design best practice question If I were to have a STRUTS enabled application where I had user types of restricted_users, full_access_users, and admins and for the most part the content of the screens the different user types get to see are the same, except for maybe Id like there to be a few extra bits of functionality on the full_access_users and admin screens that doesn't get shown on the restricted_users screen, then what's the best way to go about this? It will probably also be that each user type will require some Action objects not used by the other user types. Should I attempt to use one set of JSPs for all the different types of users and put logic inside each of the JSPs that says something like 'if the user is of type full_access_users then shown these extra few buttons', or should I give each type of user their own set of JSPs? I am tempted to try and use one set of JSPs for all user types so that I don't have to worry about maintenance of three sets of almost identical JSP files. On the other hand I feel I may be asking for security trouble by trying to have each JSP check for the user's user type - I also have a notion that checking user types is something that I should be doing elsewhere. If I do use separate JSPs for each user type, would it make sense to use the STRUTS sub-application mechanism to separate them out? Thanks for your thoughts, - Jim -- 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]
