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.We went the 'application' naming route before, why not just stick with a single term module,
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.
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]
