Scott, I just realised that what I have below is not enough. Since I use actions for all my screens (all forms you see). These need to be secured just in case someone copies a HTTP POST and uses it. So your XML definition of which permissions (or roles in my case) can use which actions and screens is looking increasingly like the only answer. Any chance of sharing the code for reading the XML file in?
thanks David -----Original Message----- From: David Wynter [mailto:[EMAIL PROTECTED]] Sent: 10 April 2002 14:50 To: Turbine Users List Subject: RE: How to approach 3 roles with separate screens? hi Scott, I had picked up on the fact you had used an XML file to define mapping from template to security from the earlier mail in the archive. This might be a bit of an overkill for me since all screens are secure and all screens are specific to a role. >From what i have been reading and what you are saying I can do the following. I think? In my LoginUser.doPerform( RunData data) (common to all roles in actions directory) ...after the data.save() call... //check if the User ( from the http request ) //has role and then setLayoutTemplate and setScreenTemplate if( acl.hasRole("Administrator") ) { data.setLayoutTemplate("Admin.vm"); data.setScreenTemplate("Admin/Welcome.vm"); } else if( acl.hasRole("Message User") ) { data.setLayoutTemplate("MsgUser.vm"); data.setScreenTemplate("MsgUser/Welcome.vm"); } else if( acl.hasRole("Extract User") ) { data.setLayoutTemplate("ExtractUser.vm"); data.setScreenTemplate("ExtractUser/Welcome.vm"); } ... The LayoutTemplates all reside in the template/layout directory and effectively replace the Default.vm. They all refer to a menu.vm in the appropriate subdirectory of the template/navigations directory. For security in each of the screens referenced by the menu.vm in each role subdirectory I have subclassed VelocitySecureScreen and called it Default.java and put it in the appropriate subdirectory (I now realise I could have just one Default.java and do what you do , get their acl check the role is appropriate for the screen). Each of these checks for the appropriate role (acl.hasRole) and directs them to the login layout an screen template if they don't have the Role. Have I covered everything here? I have just started coding this new stuff so stop me if I am making a mistake here. I must say valves in T3 sounds a much cleaner pattern and easier for old folk like me to understand. Regards and your advice is much appreciated. David -----Original Message----- From: Weaver, Scott [mailto:[EMAIL PROTECTED]] Sent: 10 April 2002 14:09 To: 'Turbine Users List' Subject: RE: How to approach 3 roles with separate screens? > But I am not sure how to tie this in with the screens, > do I have 3 > subclasses from VelocitySecureScreen in subdirectories that match the > pattern on the template subdirectories? com.yourapp.app.modules.screens.{directory_structure_under_screens}.Template Name.class or if you want all screens in that directory to use the same screen class: com.yourapp.app.modules.screens.{directory_structure_under_screens}.Default. class > Is this the best > approach? Will it > carry over to Turbine 3? >From what I know, Turbine 3 will support the classic turbine layout, navigation and screen methodology as an option. However, I think the push will be to use the valve architecture T3 implements to provide for things like view control (templates), template security, etc. I personally have use a single screen class for my entire application. The isAuthorized() method checks a custom xml file (using the template's name) via a session tool/service combination to figure out whether or not the template is secure and if it is secure, I use the session tool to validate the current users ACL against the requirements for that template. This allows quite a it more flexibility then having to hard code security into individual screen classes. If you are relying heavily on code in your screen classes, I would highly recommend moving that logic into pull tools. I say this because (someone correct me if I'm wrong) that appears to be the T3 way of doing things as opposed to screen classes. Scott > -----Original Message----- > From: David Wynter [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 10, 2002 4:14 AM > To: Turbine-User > Subject: How to approach 3 roles with separate screens? > > > I have been through the archives to see how to best approach > my requirement. > I find I am still missing something. > > I currently have a single role with one permission and use a > pull tool and > just one subclass of VelocitySecureScreen for all the screens > used by that > role. I need to add 2 more roles (all need security) each > with a single > permission each with unique screens (there are no screens > which are shared > by the roles). > > I found the mail in the archive > http://marc.theaimsgroup.com/?l=turbine-user&m=101043436816718&w=2 > This suggests using subdirectories for weak and secure > screens. I assume I > can use the same approach and have 3 template sub-directries, > one for each > role. But I am not sure how to tie this in with the screens, > do I have 3 > subclasses from VelocitySecureScreen in subdirectories that match the > pattern on the template subdirectories? Is this the best > approach? Will it > carry over to Turbine 3? > > thanks > > David > > > > -- > 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]>
