Hi,
Following up on my previous note I have found an example of switching the
layout template on-the-fly. In fact this example code was from the
example "newapp" from tdk2.1! Here is the method that does it, from the
FluxScreen.java file from newapp (you might want to look over the source
for newapp for details):
/**
* Overide this method to perform the security check needed.
*
* @param data Turbine information.
* @return True if the user is authorized to access the screen.
* @exception Exception, a generic exception.
*/
protected boolean isAuthorized( RunData data ) throws Exception
{
boolean isAuthorized = false;
/*
* Grab the Flux Admin role listed in the Flux.properties
* file that is included in the the standard
* TurbineResources.properties file.
*/
String fluxAdminRole =
TurbineResources.getString("flux.admin.role");
AccessControlList acl = data.getACL();
if (acl==null || ! acl.hasRole(fluxAdminRole))
{
data.getTemplateInfo().setScreenTemplate(
TurbineResources.getString("template.login"));
data.setScreen(
TurbineResources.getString("screen.login"));
isAuthorized = false;
}
else if(acl.hasRole(fluxAdminRole))
{
isAuthorized = true;
}
if
(TurbineResources.getString("flux.mode").equalsIgnoreCase("embedded"))
{
data.getTemplateInfo().setLayoutTemplate(
TurbineResources.getString("flux.embedded.layout"));
}
else
{
/*
* This could probably be set to a default value
* because if running in stand-alone we know what
* layout template to use.
*/
data.getTemplateInfo().setLayoutTemplate(
TurbineResources.getString("flux.stand.alone.layout"));
}
return isAuthorized;
}
Regards,
Dan
On Wed, 10 Apr 2002, Dan K. wrote:
>
> Hi David,
>
> I'd definitely love to know what your final design turns out to be...can
> you please let me and/or the list know? Much appreciated.
>
> Anyway, I think this is what you want to do... You can change the layout
> used by turbine by changing the following TR.props setting:
>
> # VelocityECSLayout is used if we want Turbine to put do the layout for us
> # so that it would include the <html>, <title>, <body> start and end tags.
> services.VelocityService.default.layout = VelocityECSLayout
> --> this is the default --> ^^^^^^^^^^^^^^^^^
>
> # VelocityOnlyLayout is used if we want control our own layout so that we
> # could include our own <html>, <title>, <body> start and end tags.
> ## services.VelocityService.default.layout = VelocityOnlyLayout
> --> this is the one you want --> ^^^^^^^^^^^^^^^^^^
>
> Hey, actually, I remember reading somewhere either in the docs or the
> turbine 2.1 source that demos how to do something similar to what you
> want -- layout switch on the fly depending on the role. Now only if I
> can find it... I'll let you know, hopefully.
>
> Hope this helps.
>
> Regards,
> Dan
>
> On Wed, 10 Apr 2002, David Wynter wrote:
>
> > It becomes apparent that there is no such class as VelocitySiteLayout, so
> > the HowTo VelocitySite documentation is incorrect.
> >
> > If I understand correctly Scott's configuration from the XML file covers the
> > screens security. But in addition I want to change the layout used for
> > different screens. So now I have no idea how to set 3 different layouts for
> > 3 different roles. Has anybody done this?
> >
> >
> > David
> > -----Original Message-----
> > From: David Wynter [mailto:[EMAIL PROTECTED]]
> > Sent: 10 April 2002 19:19
> > To: Turbine Users List
> > Subject: [ANS]: How to approach 3 roles with separate screens?
> >
> >
> > On reading further down the VelocitySite howto it tells me to subclass
> > VelocitySiteLayout to override the layouts used. Fair enough I'll give it a
> > go. Sorry to have disturbed you from your work if you are reading this.
> >
> > David
> >
> > -----Original Message-----
> > From: David Wynter [mailto:[EMAIL PROTECTED]]
> > Sent: 10 April 2002 18:42
> > To: Turbine Users List
> > Subject: RE: How to approach 3 roles with separate screens?
> >
> >
> > I still seem to not understand how this works, in the code excerpt in the
> > earlier email below the calls to data.setLayoutTemplate(...) do not seem to
> > have any effect. The Admin.vm etc. template files are all in the app/layouts
> > directory but it only ever uses default.vm? Am I making this call in the
> > wrong place?
> >
> > I tried putting the following at the top of default.vm with no effect
> > either,
> >
> > #if ( $data.getACL.hasRole("Administrator") )
> > $data.setLayoutTemplate("/Admin.vm")
> > #end
> >
> > David
> >
> > -----Original Message-----
> > From: Weaver, Scott [mailto:[EMAIL PROTECTED]]
> > Sent: 10 April 2002 17:44
> > To: 'Turbine Users List'
> > 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]>
> >
> >
> > --
> > 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]>
