I'd like to take a look too!! A post to the list would be very fine!!! Thanks in advance Gunter M.
> -----Urspr�ngliche Nachricht----- > Von: Matthew Koranda [mailto:[EMAIL PROTECTED]] > Gesendet: Donnerstag, 11. April 2002 10:44 > An: Turbine Users List > Betreff: Re: How to approach 3 roles with separate screens? > > > I'd really like to take a look too, it sounds like a good technique to use > for other things as well. > Could you post it to the list? > > Thanks, > Matt > > ----- Original Message ----- > From: "Weaver, Scott" <[EMAIL PROTECTED]> > To: "'Turbine Users List'" <[EMAIL PROTECTED]> > Sent: Wednesday, April 10, 2002 6:43 PM > Subject: RE: How to approach 3 roles with separate screens? > > > > 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]> > > > > > -- > 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]>
