Re: [Design Discussion] Multiple Controllers Per Web App

[Martin Cooper <ma...@tumbleweed.com>]

Comments interspersed.

----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: "Struts Developers List" <st...@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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Design Discussion] Multiple Controllers Per Web App

[Ted Husted <hu...@apache.org>]

Martin Cooper wrote:
> I do have the book - I just haven't had time to read much of it yet. ;-) I
> didn't think I was interested in portals, but it looks like I might be
> interested in portal technology put to a different use...

Came across this on the way to something lese. Thought it might interest
you:

What essential services does a portlet API need to provide? 

* Discovery
* Authorization
* Profiles (user customization, skins)
* Presentation fragments (scrape)
* Resource configuration, application and user (profiles?)

I've had team managers tell me that what they would really like to do is
have each group working on a portlet, and then assembly them into an
application. 

Which I believe is what you are after. 

A related idea is leveraging single-logon for multiple applications. So,
you might offer a service via a traditional RSS portlet, but when they
click through they actually land in a whole 'nother application that's
sharing the login protocal and database. 


-- 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Design Discussion] Multiple Controllers Per Web App

[Martin Cooper <ma...@tumbleweed.com>]

----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Wednesday, January 02, 2002 4:58 AM
Subject: Re: [Design Discussion] Multiple Controllers Per Web App


> 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).

I do have the book - I just haven't had time to read much of it yet. ;-) I
didn't think I was interested in portals, but it looks like I might be
interested in portal technology put to a different use...

Thanks!

--
Martin Cooper


>
> 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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Design Discussion] Multiple Controllers Per Web App

[Ted Husted <hu...@apache.org>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>