I've found that using a cross module html:link tag very useful.
- We are using web.xml security restrictions on a module by
module basis (centrally managed security). For us this was mainly used
as a stop gap security measure to ensure that a poorly configured role
in a single action mapping, didn't break our security model.
- The main benefit was enhancing the html link tag to determine
if a user was "inRole" and effectively hiding links from unauthorized
users. This effectively expanded/collapsed our navigation menus based
on the users access level to the system. It is hoped that this would
avoid many frivolous emails/calls to help desk support about why a user
might be getting a 503 error. While the logic:present tag is a useful
alternative, it would have caused jsp code bloat, and managing security
access in both jsps and struts config files. (The same with the switch
action.)
i.e.: <html:link action="" module="" ...
It seemed that if you have action="" attribute, then module="" was the
next logical step with making struts modular. For us, it certainly
helped provide the glue in a very large data centric struts application.
Large obviously relative to my situation, so more specifically: 20
modules, 10 state/local government agencies, 30 roles, 10,000 users (250
core 9am-5pm users), and 6 developers.
It seems modular link and rewrite tags are a nice step in the right
direction. Well, just one perspective to consider.
Thanks.
-----Original Message-----
From: Robert Leland [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 20, 2004 10:01 PM
To: Struts Developers List
Subject: Re: Compartmentalization of Modules (was Re: [18111] et al)
Ted Husted wrote:
>Like James, I've been counseling teams to go multiple struts-configs
rather than modules, because of the issues with cross-linking and
sharing resources between modules.
>
>If we go ahead with the patch to html:link, to match the other changes
we made this week, then I wouldn't have to steer people away from
modules.
>
>As it stands, I believe the most common use case is that large teams
want to use modules as part of a divide-and-conquer strategy.
>
>I'd suggest that we go ahead an apply these remaining patches, so that
we support sharing of resources and linking between the named modules
and the default module.
>
>If someone comes up with a patch to make the contextRelative tag
attribute configurable or immutable, then we can apply that too.
>
>My one concern is that "contextRelative" is a verbose attribute name
and potentially confusing. From one perspective, the module is the
current "context" :). It really means to say applicationContextRelative,
but that's impossibly long for an attribute name.
>
>
We went the 'application' naming route before, why not just stick with a
single term module,
and call it moduleRelative ? Which is what is is, 'relative to the
current module.
>While I'm at it, how about if we turn the attribute around and
deprecate "contextRelative=true" in favor of "modular=false"?
>
>So we'd have things tags <html:img page="/assets/logo.gif"
modular="false" /> instead of <html:img page="/assets/logo.gif"
contextRelative="true" />
>
>As mentioned, once we mop this up, I believe we can roll 1.2.0. :)
>
>-Ted.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
