Design pattern for role based layout, actions and screens

[David Wynter <da...@roamware.com>]

Hi,

I have been using the VelocityECSLayout class for my role based layout. A
discussion on the pattern I use for my role based layout can be found here:
http://marc.theaimsgroup.com/?l=turbine-user&m=101897917112944&w=2

I have role specific subdirecorties under templates/app/screens,
templates/app/layouts, templates/app/navigations and I have role specific
subdirectories under <classpath to app>/modules/actions and <classpath to
app>/modules/screens. The screens role speciifc subdirectory is restricted
to Default.class which picks up the role in acl and checks it against the
role extracted from the properties file. Any screen specific titles are
substituted as described in the archive above.

I recognise that my pattern does not allow for multi roled users having
composite menus that consist of a super set of access to all unique screens
for each role.

Now that VelocityECSLayout is deprecated I am interested to hear how others
have solved the problem of titles unique to the screen. I am also interested
in the broader approach to role based segregation of templates and code.

A few things that I am guided by are:
1. I do not like screens that contain lots of logic to display items
dependent on role, too difficult to maintain
2. I use a pull tool for all entities required for display on the screen,
although the action will repopulate the context with any entities passed in
in the request. The pull tool is only used where the entity is not present
in the context.

Thanks,

David Wynter
roamware Ltd.
(+44) (0) 208 922 7539 B.
(+44) (0) 7879 605 706 M.
david@roamware.com


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

RE: Design pattern for role based layout, actions and screens

[David Wynter <da...@roamware.com>]

Might help if you see my RoleBasedLayout class to see how I select the
correct layout for the roel and why I rely on VelocityECSLayout at the
moment.

public class RoleBasedLayout extends VelocityECSLayout {
    public void doBuild(RunData data) throws Exception {
        Context context = TurbineVelocity.getContext(data);
        String returnValue = "";
        ConcreteElement results = ScreenLoader.getInstance().eval(data,
                data.getScreen());

        if (results != null) {
            returnValue = results.toString();
        }

        context.put("screen_placeholder", returnValue);
        context.put("navigation", new TemplateNavigation(data));

        AccessControlList acl = data.getACL();
        String templateName = "";

        templateName = data.getTemplateInfo().getLayoutTemplate();
        if (acl != null) {
	        String[] roles = TurbineResources.getStringArray("roles");
	        String[] roleLayouts =
TurbineResources.getStringArray("role.layout");

            for(int i=0; i<roles.length; i++)
            {
                if(acl.hasRole(roles[i]))
                {
                    templateName = roleLayouts[i];
                    break;
                }
            }
        }

        data.getPage().getBody().addElement(TurbineVelocity.handleRequest(
                context, "layouts".concat(templateName)));
    }
}

David

-----Original Message-----
From: David Wynter [mailto:david@roamware.com]
Sent: 31 December 2002 13:30
To: Turbine-User
Subject: Design pattern for role based layout, actions and screens


Hi,

I have been using the VelocityECSLayout class for my role based layout. A
discussion on the pattern I use for my role based layout can be found here:
http://marc.theaimsgroup.com/?l=turbine-user&m=101897917112944&w=2

I have role specific subdirecorties under templates/app/screens,
templates/app/layouts, templates/app/navigations and I have role specific
subdirectories under <classpath to app>/modules/actions and <classpath to
app>/modules/screens. The screens role speciifc subdirectory is restricted
to Default.class which picks up the role in acl and checks it against the
role extracted from the properties file. Any screen specific titles are
substituted as described in the archive above.

I recognise that my pattern does not allow for multi roled users having
composite menus that consist of a super set of access to all unique screens
for each role.

Now that VelocityECSLayout is deprecated I am interested to hear how others
have solved the problem of titles unique to the screen. I am also interested
in the broader approach to role based segregation of templates and code.

A few things that I am guided by are:
1. I do not like screens that contain lots of logic to display items
dependent on role, too difficult to maintain
2. I use a pull tool for all entities required for display on the screen,
although the action will repopulate the context with any entities passed in
in the request. The pull tool is only used where the entity is not present
in the context.

Thanks,

David Wynter
roamware Ltd.
(+44) (0) 208 922 7539 B.
(+44) (0) 7879 605 706 M.
david@roamware.com


--
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>