On Wed, 26 Dec 2001, Martin Cooper wrote:
> Date: Wed, 26 Dec 2001 22:35:34 -0800
> From: Martin Cooper <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: [Design Discussion] Multiple Controllers Per Web App
>
> This definitely looks promising, and in some ways simplifies on some of the
> ideas I've been mulling over recently. A few thoughts and questions:
>
> 1) I think there are four different scenarios to consider, and the
> implications would seem to be different for each.
>
> a) The sub-apps (to pick up on Ted's terminology), including the default
> sub-app, are entirely independent of each other.
> b) The non-default sub-apps are entirely independent of each other, but rely
> on the default sub-app to provide some basic functionality and/or behaviour.
> c) One sub-app may alter its own functionality and/or behaviour depending
> upon the presence or absence of another sub-app.
> d) One sub-app may rely on any other sub-app for some functionality and/or
> behaviour.
>
> It would seem that scenario (a) is the primary target of this
> proposal.Unless I'm mistaken, scenario (b) is similar to what Ted is calling
> "portlets". Scenario (d) seems more like anarchy, and I'm not sure we want
> to deal with that!
>
You're definitely correct that scenario (a) was my primary target for
this. It's the request I've heard the most often on the mailing list, and
also seemed the most consistent with the way that servlet containers deal
with individual webapps (a bias that unavoidably comes from my involvement
in Tomcat development :-). That's not at all to say that the other
scenario's aren't valid things to consider!
> Scenario (c) is something I am currently faced with, which is why I've been
> thinking about it quite a bit. ;-) A simple version of this idea is where
> the default sub-app provides some UI pages in which there are certain links
> to other pages within that sub-app. Later, when another sub-app is
> installed, some additional links should appear on those pages, linking to
> actions on the newly installed sub-app.
>
Would it make sense to think of dealing with scenario (c) by "copying"
rather than "defaulting"? I could conceive of an Ant script to build the
thing that worked like this:
* Set up directories for all of the sub-applications in the
overall deployment directory
* Copy the "default" application's JSP pages, etc. into each of the
sub-application-directories in the deployment directory
* Overwrite the deployment directory with customized versions for
this sub-application as needed.
This doesn't deal well with sharing Java code (i.e. Actions and the
corresponding beans), but it would deal with selectively overwriting pages
without having to maintain lots of copies individually.
> Expanding on scenario (b), this can be considered as an application specific
> framework (which may or may not include UI) into which plug-ins may be added
> to extend or customise it. The default sub-app is the framework, and the
> other sub-apps are the plug-ins. Now, a plug-in itself may also need to
> provide a mechanism such that an additional plug-in can extend or customise
> *it*. This is also something I am faced with. I think this is an interesting
> scenario, because it suggests the possibility of a hierarchy of sub-apps,
> rather than a single level.
>
I definitely need to think more about the idea of "inheriting" behavior
from the default sub-application ...
> 2) How would the ActionMapping.findForward() lookup work in the current
> proposal? I can think of three possibilities:
>
> a) sub-app local forwards, then sub-app global forwards
> b) sub-app local forwards, then sub-app global forwards, then default
> sub-app global forwards
> c) sub-app local forwards, then all global forwards, where the set of global
> forwards is the union of those from all sub-apps.
>
> This relates somewhat to the different scenarios presented in (1) above, but
> I think it's key to this discussion.
>
My thinking was (a), but we'll probably need a way to indicate that the
path in a <forward> declaration should be considered to be
context-relative rather than sub-application-relative (for example, so
that a menu sub-app can switch between sub-apps). The simplest way to do
this might be an extra boolean attribute on the <forward> element (and a
corresponding property on ForwardConfig).
> 3) We probably need to allow for both sub-app specific data sources and
> global data sources to accommodate 1.a and 1.b above.
In the current proposal, there was an implied (and definitely not well
documented) assumption that data sources were uniquely named across
sub-applications. The primary reason for this is that data sources are
the only case where we currently have to create some "active" object based
on the configuration data (as the Struts 1.0 mechanism does for data
sources already). In the new proposal, the DataSourceConfig object only
contains the *configuration properties* of a data source -- it's not a
data source itself. It would be feasible to make the actual data source
implementation objects local to a sub-application, but this would have
negative portability impacts on current Struts-based code.
> 4) Separating the application prefix from the application configuration is
> crucial. In my situation, the former might be selected by a customer, but I
> don't want my customers messing around in the config files...
>
Except where your customer wants all of the default functionality
*except* for a tweak here and there ... which is what makes scenarios (b)
and (c) interesting to think about.
> --
> Martin Cooper
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
