I've been sitting by the sidelines on this one, but Roy's comments got me
thinking. I think you should be able to do something along the lines of what
I have below.
Basically the composite controller is a controller singleton that has a map
of controllers (name, controller pair). Name is defined in maverick.xml. The
final model is a map keyed to controller name (i.e. the individual model
from each controller is stored in the map under its name). There is also a
map of viewNames returned from the controllers. If you extend
CompositeController, you can override the decideWhichView() method to use
this map to decide which view to return.
The nice thing is that you will get a single object back as the model which
will work equally well with any of the view types (jsp, xslt, dvsl, etc).
The biggest problem I see with this is that the decideWhichView(Map
viewNames) could pretty rapidly get out of control:
if controller a returned "success" and controller b returned "success"
and controller c returned "sucess"
return "success"
else if controller a returned "error" and controller b returned
"success" and controller c returned "sucess"
return "aerror"
else if controller a returned "success" and controller b returned
"error" and controller c returned "sucess"
return "berror"
else if controller a returned "success" and controller b returned
"success" and controller c returned "error"
return "cerror"
else if controller a returned "error" and controller b returned "error"
and controller c returned "error"
return "aberror"
and so on and so on and so on
--jim
-----------------------------------------
import java.util.*;
import javax.servlet.ServletException;
import org.infohazard.maverick.flow.*;
import org.jdom.Element;
public class CompositeController implements ControllerSingleton {
private Map controllers;
private Map model;
private Map viewNames;
private final String SUCCESS = "success";
private final String ERROR = "error";
public void init(Element controllerNode) throws ConfigException {
/*
* logic here to load up the controllers map
*
* I'm envisioning a controller node that looks like:
* <controller class="org.fcny.comnet.maverick.AddIncidents">
* <controller name="leftnav" class="com.foo.bar.LeftNav"/>
* <controller name="body" class="com.foo.bar.Body"/>
* </controller>
*
*/
}
public String go(ControllerContext cctx) throws ServletException {
model = new Hashtable();
viewNames = new Hashtable();
Iterator it = controllers.keySet().iterator();
while(it.hasNext()) {
String name = (String)it.next();
Controller c = (Controller)controllers.get(name);
String viewName = c.go(cctx);
viewNames.put(name, viewName);
//this is kind of cheating, but I can't think of a better way
Object tempModel = ((MaverickContext)cctx).getModel();
model.put(name, tempModel);
}
cctx.setModel(model);
String viewName = decideWhichView(viewNames);
return viewName;
}
/**
* You can override this to determine which view to render based on
* whatever the individual controllers returned.
*/
public String decideWhichView(Map viewNames) {
return SUCCESS;
}
}
----- Original Message -----
From: "Roy Truelove" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 09, 2002 11:28 AM
Subject: Re: [Mav-user] Assembling views
> Hey Thomas,
>
> I think that the approach you suggested is somewhat unnecessary only
> because all view technologies that Maverick supports (XSLT, JSP, Velocity,
> etc) all have their own means of handling composite pages, so that
> functionality shouldn't have to be pushed back to Maverick.
>
> In response to what Chris is looking for, I'd have to do some
brainstorming
> to think of how to handle something like this, without having to do many
> changes to Maverick.
>
> (Thinking out loud) Having multiple controllers in effect means having
> mulitple models, one for each view "component". Can't components just
share
> the same model? For instance, lets's say I have only 2 components.. a
> sidebar and then my main content. If I have a controller for my sidebar,
> and the controller for the main content *subclasses* that controller, then
> the model that's being passed to the view has the data for all of my
> components. (?) just some ideas... You might get into subclassing hell
> with this approach though.
>
> -Roy
>
>
> ----- Original Message -----
> From: "Thomas Wheeler" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, August 07, 2002 6:54 PM
> Subject: RE: [Mav-user] Assembling views
>
>
> > I guess I'm having a hard time understanding the value of composing a
page
> > out of commands instead of views; maybe I'm too steeped in traditional
> MVC,
> > where the view displays the model and the controller changes the model.
> I'm
> > honestly not even clear on how to implement a command-composition model.
> >
> > Okay, looking back at your original email (wayyyyy down there :) ), it
> looks
> > like your command names have the meaning "display this part of the page
> > (model)". So perhaps we are talking about the same approach, but using
> > different words?
> >
> > BTW -- can someone with a clue comment on the feasibility of the
approach
> I
> > described below?
> >
> > -Thomas
> >
> > -----Original Message-----
> > From: Christoph Sturm [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, August 07, 2002 4:05 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Mav-user] Assembling views
> >
> >
> > Hi Tom!
> >
> > Thanks for your replies!
> > I think your proposal is to compose a view out of other views, but my
> > porposal was to compose it out of whole commands with their view
> > pipelines. Or am I missing something?
> > I think every view needs its command, because this results in smaller
> > commands and thus more code reuse.
> >
> > regards
> > chris
> >
> >
> > Thomas Wheeler wrote:
> >
> > >I spent a little time looking at this (composite views) last night.
I'm
> a
> > >Maverick newbie, so think of this as the ignorant ravings of a
madman --
> > but
> > >maybe it'll spark an idea in someone who knows it better.
> > >
> > >Here's what I came up with as a possibility for the XML configuration
to
> > >allow a CompositeView. The basic idea is to introduce a new view type,
> > >CompositeView, with a CompositeViewFactory as the factory. This is
> > >represented under the <modules> tag. Then, under global views, you can
> > >define a composite view as a list of other global views you want to
> include
> > >in the output. See the <views> section: the 'main' view is a composite
> > >consisting of the 'header' and 'good' views. You would then reference
> this
> > >composite view like any other global view.
> > >
> > >In looking at the Maverick code and XML configuration, I think this XML
> > >format makes sense. I'm not at all confident it can be implemented.
My
> > >biggest concern is in the processing of the views. If a view is a
> > redirect,
> > >the output from the previous views will be lost or an
> IllegalStateException
> > >will be thrown. And I'm not sure how transforms would work either.
> > >
> > >Here's an XML fragment showing the configuration of a composite view:
> > >
> > ><modules>
> > > <view-factory type='composite' provider='blah.CompositeViewFactory'>
> > ></modules>
> > ><views>
> > > <view id='good' path='good.jsp'/>
> > > <view id='header' path='header.jsp'>
> > > <view id='main' type='composite'>
> > > <view ref='header'/>
> > > <view ref='good'/>
> > > </view>
> > ></views>
> > >
> > >-Thomas
> > >
> > >-----Original Message-----
> > >From: Thomas Wheeler [mailto:[EMAIL PROTECTED]]
> > >Sent: Tuesday, August 06, 2002 5:36 PM
> > >To: '[EMAIL PROTECTED]'
> > >Subject: RE: [Mav-user] Assembling views
> > >
> > >
> > >This sounds interesting. One of my (minor) areas of concern is caching
> > >"stable" content such as navigation bars to reduce the performance hit
of
> > >generating the whole page dynamically every time through Velocity or
XSL.
> > >If there was a way to compose a page from different components, it
should
> > be
> > >easier to implement a caching strategy. And I also like the idea of
page
> > >composition through components.
> > >
> > >Maybe there's a way to do this through a CompositeView or something.
> I'll
> > >have a look at it this evening.
> > >
> > >-Thomas
> > >
> > >-----Original Message-----
> > >From: Christoph Sturm [mailto:[EMAIL PROTECTED]]
> > >Sent: Tuesday, August 06, 2002 4:15 PM
> > >To: [EMAIL PROTECTED]
> > >Subject: Re: [Mav-user] Assembling views
> > >
> > >
> > >Hi Roy!
> > >
> > >Basically I am trying to archive just that. I dont want one controller
> > >for one screen, but one controller for one component, and screens
> > >assembled from these components. I could just include other commands
> > >from the view, and assemble my page there, this is how its done in
> > >webwork for example, maybe its better to do it like this.
> > >
> > >Either way it would just be great if I could get the result of a
> > >maverick command and its view viewpipeline in a string or a writer. An
> > >really easy solution to that that would be to change MaverickContext to
> > >be servlet-agnostic. That would make it easy for me to implement what I
> > >had in mind.
> > >
> > >regards
> > > chris
> > >
> > >
> > >Roy Truelove wrote:
> > >
> > >
> > >
> > >>Hi Chris,
> > >>
> > >> I guess the main advantage of doing something like this is that
each
> > >>component would first go through a controller, as opposed to somethink
> > like
> > >>Tiles or JSP includes where this is not the case. Is that the only
> > >>functionality that it would provide? Because it would seem easier to
> just
> > >>do composites purely on the view side of things. I've never really
had
> a
> > >>need for my sidebar, header, etc. to have to go through a controller,
> but
> > >>that doesn't mean that other people haven't.
> > >>
> > >>-Roy
> > >>
> > >>----- Original Message -----
> > >>From: "Christoph Sturm" <[EMAIL PROTECTED]>
> > >>To: <[EMAIL PROTECTED]>
> > >>Sent: Monday, July 29, 2002 5:01 PM
> > >>Subject: [Mav-user] Assembling views
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>>Hey all!
> > >>>
> > >>>I'd like to implement some kind of component architecture on top of
> > >>>maverick. All components are declared as normal maverick commands:
> > >>><commands>
> > >>> <command name="topnavi">
> > >>> <controller class="com.schaumwelt.controller.Navigation"/>
> > >>> <view path="topnavi.vm"/>
> > >>> </command>
> > >>> <command name="subnavi">
> > >>> <controller class="com.schaumwelt.controller.Navigation"/>
> > >>> <view path="subnavi.vm">
> > >>> </view>
> > >>> </command>
> > >>> <command name="content">
> > >>> <controller
> class="com.schaumwelt.controller.ContentViewer"/>
> > >>> <view path="content.vm">
> > >>> </view>
> > >>> </command>
> > >>></commands>
> > >>>
> > >>>One screen would then be configured like this:
> > >>>
> > >>><pages>
> > >>><page name="mainBrowser">
> > >>><component command="topnavi" name="topnavi">
> > >>> <!-- call the "topnavi" command, and store the result of the
> > >>>viewpipeline in "topnavi"
> > >>> Assign the request parameter called category to the bean property
> > >>>category -->
> > >>> <parameter name="category" value="category" source="request">
> > >>></component>
> > >>><component command="subnavi" name="subnavi">
> > >>> <!-- call the "subnavi" command, and store the result of the
> > >>>viewpipeline in "subnavi"
> > >>> Assign the bean output parameter "category" of the topnavi
command
> > >>>to the the category property of this bean -->
> > >>> <parameter name="category" value="category" source="topnavi">
> > >>></component>
> > >>><component command="content" name="content">
> > >>> <!-- call the "content" command, and store the result of the
> > >>>viewpipeline in "content"
> > >>> Assign the bean output parameter "article" of the subnavi command
> > >>>to the the article property of this bean -->
> > >>> <parameter name="article" value="article" source="subnavi">
> > >>></component>
> > >>><view path="pagelayout.vm"/>
> > >>><!-- pagelayout.vm composes the resulting page -->
> > >>></page>
> > >>></pages>
> > >>>
> > >>>page.vm would then look like this:
> > >>><html>
> > >>><head>
> > >>></head>
> > >>><body>
> > >>><table>
> > >>><tr><td colspan="2">$model.topnavi</td></tr>
> > >>><tr><td>$model.subnavi</td><td>$model.content</td></tr>
> > >>></table>
> > >>>
> > >>>This would make it really easy to create portal applications. It
would
> > >>>also have the advantage that one command only has to take care of one
> > >>>thing, and it would be easier to reuse commands on different pages.
> > >>>
> > >>>This could also be implemented without really changing Maverick
> > >>>One easy way would be to create a CompositeController, that gets the
> > >>>page definition passed as child nodes in maverick.xml, or just the
name
> > >>>of the page definition as attribute.
> > >>>
> > >>> <command name="mainBrowser" definition="mainBrowser">
> > >>> <controller
> > >>>class="com.schaumwelt.controller.CompositeController"/>
> > >>> <view path="pagelayout.vm"/>
> > >>> </command>
> > >>>
> > >>>(in this case it would look up the page named "mainBrowser" in a
> > >>>different config file, call all the commands defined in it, and store
> > >>>their result into a resulting model, which is then rendered through a
> > >>>maverick pipeline.
> > >>>
> > >>>
> > >>>What do you guys think?
> > >>>
> > >>>regards
> > >>>chris
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>-------------------------------------------------------
> > >>>This sf.net email is sponsored by: Dice - The leading online job
board
> > >>>for high-tech professionals. Search and apply for tech jobs today!
> > >>>http://seeker.dice.com/seeker.epl?rel_code=31
> > >>>_______________________________________________
> > >>>Mav-user mailing list
> > >>>[EMAIL PROTECTED]
> > >>>https://lists.sourceforge.net/lists/listinfo/mav-user
> > >>>Archives are available at http://www.mail-archive.com/
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>-------------------------------------------------------
> > >>This sf.net email is sponsored by: Dice - The leading online job board
> > >>for high-tech professionals. Search and apply for tech jobs today!
> > >>http://seeker.dice.com/seeker.epl?rel_code=31
> > >>_______________________________________________
> > >>Mav-user mailing list
> > >>[EMAIL PROTECTED]
> > >>https://lists.sourceforge.net/lists/listinfo/mav-user
> > >>Archives are available at http://www.mail-archive.com/
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > >
> > >
> > >-------------------------------------------------------
> > >This sf.net email is sponsored by:ThinkGeek
> > >Welcome to geek heaven.
> > >http://thinkgeek.com/sf
> > >_______________________________________________
> > >Mav-user mailing list
> > >[EMAIL PROTECTED]
> > >https://lists.sourceforge.net/lists/listinfo/mav-user
> > >Archives are available at http://www.mail-archive.com/
> > >
> > >
> > >-------------------------------------------------------
> > >This sf.net email is sponsored by:ThinkGeek
> > >Welcome to geek heaven.
> > >http://thinkgeek.com/sf
> > >_______________________________________________
> > >Mav-user mailing list
> > >[EMAIL PROTECTED]
> > >https://lists.sourceforge.net/lists/listinfo/mav-user
> > >Archives are available at http://www.mail-archive.com/
> > >
> > >
> > >-------------------------------------------------------
> > >This sf.net email is sponsored by:ThinkGeek
> > >Welcome to geek heaven.
> > >http://thinkgeek.com/sf
> > >_______________________________________________
> > >Mav-user mailing list
> > >[EMAIL PROTECTED]
> > >https://lists.sourceforge.net/lists/listinfo/mav-user
> > >Archives are available at http://www.mail-archive.com/
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Mav-user mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/mav-user
> > Archives are available at http://www.mail-archive.com/
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Mav-user mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/mav-user
> > Archives are available at http://www.mail-archive.com/
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Mav-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/mav-user
> Archives are available at http://www.mail-archive.com/
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user
Archives are available at http://www.mail-archive.com/
