struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary D Ashley Jr." <GaryAsh...@ToughGuy.net>
Subject RE: Compartmentalization of Modules (was Re: [18111] et al)
Date Thu, 22 Jan 2004 07:00:55 GMT
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:rleland@apache.org] 
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: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Mime
View raw message