Hi David,
Two possible solutions:
1. Have you tried either of these ?
data.setLayout( "Popup.vm" );
setLayout( data, "Popup.vm" );
2. When you call a specific screen in a directory like
/templates/newapp/screens/test/test.vm turbine will first try to find a
matching layout for this screen. Trubine will look for the following (At
least i think so):
- /templates/newapp/layout/test/test.vm
- /templates/newapp/layout/test/Default.vm
- /templates/newapp/layout/Default.vm
I have three differnt roles in my application that have diffent layouts
depending on what stage a user is in. First the can be just a visitor -> the
get the Default Layout. The the can apply to become a member. I transfer
them to the applicant screen in the applicant directory with the
correcponding Default layout in the applicant Directory. When the become a
member the move to the Member Screen and Layouts etc...
I hope this helps you.
Diederik de Groot
Talon v.o.f.
the Netherlands
> -----Original Message-----
> From: Dan K. [mailto:[EMAIL PROTECTED]]
> Sent: donderdag 11 april 2002 0:06
> To: Turbine Users List
> Subject: Re: [notANS]: How to approach 3 roles with separate screens?
>
>
>
> 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]>
