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. 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. 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 "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]>
