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!
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.
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.
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.
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.
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...
--
Martin Cooper
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 26, 2001 11:53 AM
Subject: [Design Discussion] Multiple Controllers Per Web App
> One of the highly requested features for Struts has been the concept of
> wanting to define multiple "applications" (or multiple "controllers")
> within a single Struts-based web application. Implementing this feature
> in the current controller servlet is pretty complicated, due to its
> assumpations all over the code that there is only one controller.
>
> Recent discussions on the STRUTS-DEV list, some thought that Ted Husted
> put in on the "ContextHelper" class recently checked in, and a little bit
> of time (Sun is shut down this week, so I've got a little quality time to
> put in on Struts) leads me to propose a way to accomplish the goals of
> multiple applications, using a single controller servlet, in a way that
> should remain backwards-compatible for current users (which is *always* a
> very important consideration IMHO).
>
> The basic design would include the following elements:
>
> * Running multiple "applications" within a single web app will be
> accomplished by defining each "application" to have a particular
> prefix on the context relative path. Thus, a complete request
> URI gets divided into:
>
> /{context-path}/{application-prefix}/{action-select-path}
>
> * When the controller processes an incoming request, it will parse
> the request URI and try to match it to a particular "application
> configuration" by matching against the application prefixes it
> knows about, in a manner similar to how a servlet container figures
> out which web app to run by matching against the context paths
> that it knows about.
>
> * In addition to the defined application prefixes, there will be a
> "default" application that processes all requests that cannot be
> assigned to any other application. This default application will
> be configured *exactly* as the current one-and-only application is
> defined, thus maximizing backwards compatibility.
>
> * Each application that is defined will have its own struts-config.xml
> file. The initialization parameters of the controller servlet will
> define an application prefix, and corresponding path to the config file,
> for each supported application.
>
> * Internally, all of the static configuration information from a
> particular struts-config.xml file will be organized into a single
> "application configuration" object. I've checked in a new package
> of classes (org.apache.struts.config) to represent this data. Each
> ApplicationConfig object will be exposed as a servlet context attribute,
> rather than all of the individual objects (ActionMappings,
> ActionForwards, and so on). LIKELY EXCEPTION: The actual
> javax.sql.DataSource objects for connection pools.
>
> * All cases of "context-relative" paths in the current Struts environment
> will be modified to be "application-relative" instead. This allows you
> to configure an application's XML file completely independent of the
> application prefix that will be assigned -- exactly the way a web app is
> independent of the context path to which it is assigned. (Note also
> that this still works for the "default" application -- think of this as
> having a zero-length String as the prefix, so that all application
> relative paths are actually context relative.
>
> * All logic in the existing classes (and custom tag implementations) that
> currently looks up the configuration information in servlet context
> attributes, or via method calls on ActionServlet, will need to be
> modified to look up the info for the current application instead. To
> facilitate this, we'll add a utility method to RequestUtils that looks
> up the appropriate ApplicationConfig object for a given request URI.
>
> * Existing classes in org.apache.struts.action that represent the config
> information will be deprecated in favor of the new classes in
> org.apache.struts.config. The exception will be ActionMapping (because
> it is passed as an argument to the perform() method of action classes),
> but ActionMapping will be modified to subclass
> org.apache.struts.config.ActionConfig instead of being its own class.
> This maximizes backwards compatibility, but *will* require applications
> to be compiled against the version of Struts that they are going to
> be run against (not a big restriction, IMHO).
>
> What do you think? Does this sound like a strategy that can accomplish
> the "multiple controllers" feature request without messing up existing
> Struts based applications?
>
> Craig McClanahan
>
>
>
>
>
> --
> 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]>
