Comments interspersed.
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, December 26, 2001 11:03 PM
Subject: Re: [Design Discussion] Multiple Controllers Per Web App
>
>
> 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!
I should have been more clear. I wasn't suggesting that the proposal needs
to be expanded to handle all of these scenarios (or at least a through c)
right now. Rather, I wanted to throw them out as food for thought as this
discussion progresses. I absolutely agree that (a) is clearly the
most-requested of these to date.
> > 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.
I don't think this would work for the particular case that I am working with
right now, and which spurred my previous comments. I know this is a bit (!)
of a tangent to the original discussion, but let me describe the situation
in a little more detail so that you can see where I'm coming from.
Imagine that I have a common framework which is my default Struts web app.
Let's call it 'Common'. ;-) In addition, I have two sub-apps, 'App1' and
'App2', neither of which have any knowledge of the other, although both know
about 'Common'. At any given customer site, 'Common' will always be
installed, and one or both of 'App1' and 'App2' will be installed. Further,
the sub-apps need not be installed at the same point in time, and may be
independently uninstalled. That is, I have an incremental installer and
uninstaller.
Now, there are some pages which are part of 'Common' that have a menu
somewhere on the page. If both sub-apps are installed, the menu might look
like:
Common | App1 | App2
However, if a sub-app ('App1' or 'App2') is not installed, the corresponding
link should not appear.
To further complicate the issue, I need to be able to deploy a new sub-app
(e.g. 'App3') without requiring changes to 'Common' (or 'App1' or 'App2',
for that matter), so I can't use simple conditional code to determine how to
display the menu.
I realise that this is a far cry from "Multiple Controllers Per Web App".
Sorry about that. On the other hand, I think it's always good to throw some
real-world, and perhaps more complicated, examples into the ring when
starting to think about new approaches.
> > 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).
In the scenario I described above, it would be nice if 'AppN' could forward
to a global forward defined by 'Common', so that almost the only thing it
knew about 'Common' was the names of the predefined forwards it could use,
and the installer and uninstaller knew nothing.
> > 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.
That sounds just fine.
> > 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
--
Martin Cooper
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
