Return-Path: Delivered-To: apmail-jakarta-struts-dev-archive@www.apache.org Received: (qmail 82117 invoked from network); 23 Jan 2004 05:48:58 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 23 Jan 2004 05:48:58 -0000 Received: (qmail 39116 invoked by uid 500); 23 Jan 2004 05:48:16 -0000 Delivered-To: apmail-jakarta-struts-dev-archive@jakarta.apache.org Received: (qmail 39063 invoked by uid 500); 23 Jan 2004 05:48:16 -0000 Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list struts-dev@jakarta.apache.org Received: (qmail 38949 invoked from network); 23 Jan 2004 05:48:15 -0000 Received: from unknown (HELO perpetua.mcclan.net) (208.161.106.6) by daedalus.apache.org with SMTP; 23 Jan 2004 05:48:15 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by perpetua.mcclan.net (8.12.8/8.12.8) with ESMTP id i0N5mLiF004721 for ; Thu, 22 Jan 2004 21:48:21 -0800 Received: from localhost (localhost [127.0.0.1]) by localhost (IMP) with HTTP for ; Thu, 22 Jan 2004 21:48:21 -0800 Message-ID: <1074836901.4010b5a580389@localhost> Date: Thu, 22 Jan 2004 21:48:21 -0800 From: "Craig R. McClanahan" To: Struts Developers List Subject: Re: Compartmentalization of Modules (was Re: [18111] et al) References: <2004122235241.058206@PC15> In-Reply-To: <2004122235241.058206@PC15> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 127.0.0.1 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Quoting Ted Husted : > I'm still working on the changes and refactorings to add contextRelative to > the link and rewrite tags. I'll post those first, and then do the changes to > deprecate contextRelative in favor of module. > > -T. > Orthogonal to adding a "module" attribute and other sorts of things associated with this thread (I agree with the things I've read along that line), I remember that Martin proposed (*many* moons ago) the idea that module configurations might be organized hierarchically -- they would inherit default behavior from a parent module in a manner similar to how Tiles do it. If that is not in the current thinking, it would still be something worth thinking about for the future. Just thinking out loud, we could keep the existing non-hierarchical behavior as a default (for backwards compatibility), but add a "parent module" attribute into ModuleConfig to enable one to define the inheritance hierarchy. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: struts-dev-help@jakarta.apache.org