Sure, I actually donated a rough draft of the original into the new Turbine 3 project. I will send you the most recent one I am using in production when I get a free moment.
Scott > -----Original Message----- > From: David Wynter [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 10, 2002 10:46 AM > To: Turbine Users List > Subject: RE: How to approach 3 roles with separate screens? > > > 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_scr > eens}.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_scr > eens}.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]>
