Comments interspersed. ----- Original Message ----- From: "Ted Husted" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> 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:[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]>
