struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <martin.coo...@tumbleweed.com>
Subject Re: [Design Discussion] Multiple Controllers Per Web App
Date Wed, 02 Jan 2002 08:10:21 GMT
Comments interspersed.

----- Original Message -----
From: "Ted Husted" <husted@apache.org>
To: "Struts Developers List" <struts-dev@jakarta.apache.org>
Sent: Friday, December 28, 2001 5:50 AM
Subject: Re: [Design Discussion] Multiple Controllers Per Web App


> Martin Cooper wrote:
> > 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.
>
> I think making those links appear or disappear might be outside the
> scope of the framework, since this becoming application specific. We're
> getting past a framework and into something like Jetspeed.

Yes, you could be right that it's outside the (Struts) framework. From my
perspective, it's still a part of *some* framework, though. Perhaps it's the
purview of a separate web-app plug-in framework. I haven't looked at
Jetspeed, but maybe that's what I need. Or perhaps I need something new.

> I can see something providing this sort of functionality, but it should
> be a third-party GUI thing, rather than something written into the core
> framework. Though, we should think about what kind of API something
> might need to do something like this. Being able to walk the
> context/forward tree might be enough, and the rest could be up to the
> implementation. Perhaps there could also be a "public" and "key"
> property for a forward to indicate whether is should be listed on a
> menu, and message resource key to what it should be called when it is
> listed.

I was really just suggesting that, as you said, "we should think about what
kind of API something might need to do something like this".

> In a team environment, what could happen is that when the page is
> designed, it could refer to links in the root context. Later when the
> sub-app was installed, the stub links in the core could be removed, and
> then the forward to sub-app could kick in.
>
> default
> /logon/Form.do
>
> sub-app1
> path=/logon/form.do
> root=true
>
> [logon subapp is installed]
>
> default
> -1 /logon/Form.do
>
> logon app
> /Form.do

If I understand correctly, that works for the first sub-app. But what
happens when the second sub-app is installed, or, worse, when the first
sub-app is uninstalled after the second sub-app is installed?

--
Martin Cooper


> "Craig R. McClanahan" wrote:
> > I definitely need to think more about the idea of "inheriting" behavior
> > from the default sub-application ...
>
> I think once we shipped this, people will start asking for this a lot.
>
> The idea would be that the application has a core configuration with the
> objects and resources everyone on the team is going to use, and then
> each "sub-team" can build on these for their "sub-app". If we need to
> make an application-wide change, then we can change the core, and find
> everyone in synch.
>
> The idea is exactly the same as checking for a local forward then for a
> global forward, except now we can add checking for a default forward,
> before it goes "unknown" or we throw a 404. (This would also imply that
> the default "unknown" mapping would always win, I guess.)
>
> I think it would be very useful to apply this scoping across the board,
> so that it applies to every element int he configuration, as well a the
> message resources.
>
> As we discuss this, it might also be useful to talk about a "preference"
> resource. Here we could search for a custom setting for a user that has
> been stored in properties file keyed for that use.
>
> Once this ships, I do think a lot of people will use it to create
> portlets, an idea which is already supported by several containers and
> packages, including WebSphere and Jetspeed. Here someone can create a
> utility logon application, or a stock portfolio, or file manager, and
> then plug it into larger applications.
>
> WebSphere and Jetspeed have worked on an entire specification for this,
> which duplicates the Servlet spec -- right down to PAR files to
> distribute it. I've looked at this very carefully, and finally decided
> it was not something I wanted to work on myself. There was just too much
> duplication of effort to get a single level of nesting.
>
> Here, we can achieve all the same benefits without the complications.
> But people will soon expect that they can plug a sub-app in and have it
> inherit behavior from their root app. The two things that could address
> this would be looking to the default app for anything not found in a sub
> app, and a simple user preference resource, a kin to the message
> resources.
>
> So, there would be two types of references. The first being like the way
> the forwards work, except that the default application context is alos
> checked. The second being a "root" reference that says don't even look
> at my context, but start from the application root. We probably need a
> property for this, since the installed base will have leading back
> slashes in many of the action paths or forward names.
>
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/struts/
>
> --
> To unsubscribe, e-mail:
<mailto:struts-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:struts-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message