Martin Cooper wrote:
> 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.
Jetspeed does do this sort of thing. You can add a new syndication
channel, and it puts it on a menu where people can subscribe to it. See
chapter 14 of Pro JSP Sites (which I remember you mentioned having).
With Craig's proposed changes, people could then build a Jetspeed-like
product over the Struts framework. But I think we all agree that this
goes past "framework" and is more of an "environment" -- like Turbine
was before they started dismantling it.
> > 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?
Someone on the team would have to make adjustments. I'm not suggesting
this is a consumer-grade approach, but what a corporate team could do by
hand, in lieu of using a Jetspeed-like environment.
> 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.
+1 on someone working on a Jetspeed-like environment
("installer/uninstaller) to demonstrate what could be built on top of
the multiple-applications framework. Some early work here might prevent
mis-steps.
For example, perhaps we should have "public" and "label" properties on
the forwards to indicate whether a dynamic menu should automatically
expose them. But its difficult to say for sure without a use case.
I'm just thinking it should be like Struts Camino or Struts Console, a
separate GUI product that can be used with Struts, but doesn't need to
be in the main Struts JAR.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
