You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by David Wynter <da...@btclick.com> on 2002/04/10 21:22:53 UTC

[notANS]: How to approach 3 roles with separate screens?

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:david.wynter@btclick.com]
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:david.wynter@btclick.com]
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:Sweaver@rippe.com]
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:david.wynter@btclick.com]
> 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:david.wynter@btclick.com]
> 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:Sweaver@rippe.com]
> 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:david.wynter@btclick.com]
> > 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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: [notANS]: How to approach 3 roles with separate screens?

Posted by Diederik de Groot <dd...@talon.nl>.
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:dantest@YorkU.CA]
> 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:david.wynter@btclick.com]
> > 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:david.wynter@btclick.com]
> > 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:Sweaver@rippe.com]
> > 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:david.wynter@btclick.com]
> > > 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:david.wynter@btclick.com]
> > > 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:Sweaver@rippe.com]
> > > 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:david.wynter@btclick.com]
> > > > 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:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [notANS]: How to approach 3 roles with separate screens?

Posted by "Dan K." <da...@YorkU.CA>.
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:david.wynter@btclick.com]
> > 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:david.wynter@btclick.com]
> > 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:Sweaver@rippe.com]
> > 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:david.wynter@btclick.com]
> > > 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:david.wynter@btclick.com]
> > > 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:Sweaver@rippe.com]
> > > 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:david.wynter@btclick.com]
> > > > 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:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [notANS]: How to approach 3 roles with separate screens?

Posted by "Dan K." <da...@YorkU.CA>.
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:david.wynter@btclick.com]
> 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:david.wynter@btclick.com]
> 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:Sweaver@rippe.com]
> 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:david.wynter@btclick.com]
> > 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:david.wynter@btclick.com]
> > 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:Sweaver@rippe.com]
> > 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:david.wynter@btclick.com]
> > > 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:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Selecting different layouts is very difficult, help!

Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
Hi, my problem was a little different from yours but I think my
solutions applies.
I have a turbine app that host multiple projects, each project has it's
own look and feel ( each project has it's own layout template)
What I did was :
-> change TR.conf to use my own impl of Layout
-> extend VelovityLayout to look up layout templates based on some
criteria ( project in Session, user.getProject(), etc)
-> extend TemplateLink to allow $link.setLayout() link styles.

I think this solution works pretty well, I fact MyLayout calls MyScreen
to resolve the layout template name.

OBS 1 - this works only for T2
OBS 2 - it would be nice to patch turbine to work like this : have
Layout call Screen for template name, like
screen.getLayoutTemplateName.

I can send you the files if you want.

On Wed, 2002-04-10 at 18:47, David Wynter wrote:
> After a considerable journey trying everything I can think of I have been
> unsuccessful in finding a way to select a layout specific to a role. The
> last thing I tried was putting the following conditional stuff in the table
> in the default.vm
> 
> #if ( $data.getACL.hasRole("Administrator") )
>   <tr>
>     <td colspan="3">
>       $navigation.setTemplate("/DefaultTop.vm")
>     </td>
>   </tr>
>   <tr>
>     <td width="$ui.menuWidth" align="left" valign="top">
>       $navigation.setTemplate("AdminMenu.vm")
>     </td>
> 	<td BGCOLOR="#86BE40" width="1">
> 		<img src="$content.getURI("images/apixltgrn.gif")" height="100%"
> width="1">
> 	</td>
>     <td align="left" valign="top" width="$ui.screenTableWidth">
>       $screen_placeholder
>     </td>
>   </tr>
>   <tr>
>     <td colspan="3">
>       $navigation.setTemplate("/DefaultBottom.vm")
>     </td>
>   </tr>
> 
> #end
> #if ( $data.getACL.hasRole("Extract User") )
>   <tr>
>     <td width="$ui.menuWidth" align="left" valign="top">
>       $navigation.setTemplate("ExtractMenu.vm")
>     </td>
> 	<td BGCOLOR="#86BE40" width="1">
> 		<img src="$content.getURI("images/apixltgrn.gif")" height="100%"
> width="1">
> 	</td>
>     <td align="left" valign="top" width="$ui.screenTableWidth">
>       $screen_placeholder
>     </td>
>   </tr>
>   <tr>
>     <td colspan="3">
>       $navigation.setTemplate("/DefaultBottom.vm")
>     </td>
>   </tr>
> #end
> #if ( $data.getACL.hasRole("Message User") )
>   <tr>
>     <td>
>       $navigation.setTemplate("/DefaultTop.vm")
>     </td>
>   </tr>
>   <tr>
>     <td align="left" valign="top" width="$ui.screenTableWidth">
>       $screen_placeholder
>     </td>
>   </tr>
>   <tr>
>     <td>
>       $navigation.setTemplate("/DefaultBottom.vm")
>     </td>
>   </tr>
> #end
> 
> Now I get a blank screen!
> 
> Is it actually possible to do this?
> 
> David
> 
> -----Original Message-----
> From: David Wynter [mailto:david.wynter@btclick.com]
> Sent: 10 April 2002 20:23
> To: Turbine Users List
> Subject: [notANS]: How to approach 3 roles with separate screens?
> 
> 
> 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:david.wynter@btclick.com]
> 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:david.wynter@btclick.com]
> 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:Sweaver@rippe.com]
> 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:david.wynter@btclick.com]
> > 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:david.wynter@btclick.com]
> > 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:Sweaver@rippe.com]
> > 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:david.wynter@btclick.com]
> > > 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:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
-- 
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)
http://www.ibnetwork.com.br


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Selecting different layouts is very difficult, help!

Posted by David Wynter <da...@btclick.com>.
After a considerable journey trying everything I can think of I have been
unsuccessful in finding a way to select a layout specific to a role. The
last thing I tried was putting the following conditional stuff in the table
in the default.vm

#if ( $data.getACL.hasRole("Administrator") )
  <tr>
    <td colspan="3">
      $navigation.setTemplate("/DefaultTop.vm")
    </td>
  </tr>
  <tr>
    <td width="$ui.menuWidth" align="left" valign="top">
      $navigation.setTemplate("AdminMenu.vm")
    </td>
	<td BGCOLOR="#86BE40" width="1">
		<img src="$content.getURI("images/apixltgrn.gif")" height="100%"
width="1">
	</td>
    <td align="left" valign="top" width="$ui.screenTableWidth">
      $screen_placeholder
    </td>
  </tr>
  <tr>
    <td colspan="3">
      $navigation.setTemplate("/DefaultBottom.vm")
    </td>
  </tr>

#end
#if ( $data.getACL.hasRole("Extract User") )
  <tr>
    <td width="$ui.menuWidth" align="left" valign="top">
      $navigation.setTemplate("ExtractMenu.vm")
    </td>
	<td BGCOLOR="#86BE40" width="1">
		<img src="$content.getURI("images/apixltgrn.gif")" height="100%"
width="1">
	</td>
    <td align="left" valign="top" width="$ui.screenTableWidth">
      $screen_placeholder
    </td>
  </tr>
  <tr>
    <td colspan="3">
      $navigation.setTemplate("/DefaultBottom.vm")
    </td>
  </tr>
#end
#if ( $data.getACL.hasRole("Message User") )
  <tr>
    <td>
      $navigation.setTemplate("/DefaultTop.vm")
    </td>
  </tr>
  <tr>
    <td align="left" valign="top" width="$ui.screenTableWidth">
      $screen_placeholder
    </td>
  </tr>
  <tr>
    <td>
      $navigation.setTemplate("/DefaultBottom.vm")
    </td>
  </tr>
#end

Now I get a blank screen!

Is it actually possible to do this?

David

-----Original Message-----
From: David Wynter [mailto:david.wynter@btclick.com]
Sent: 10 April 2002 20:23
To: Turbine Users List
Subject: [notANS]: How to approach 3 roles with separate screens?


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:david.wynter@btclick.com]
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:david.wynter@btclick.com]
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:Sweaver@rippe.com]
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:david.wynter@btclick.com]
> 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:david.wynter@btclick.com]
> 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:Sweaver@rippe.com]
> 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:david.wynter@btclick.com]
> > 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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>