One complication is that right now, each invocation of a maverick
command (forwarding to a document view with a path like "next.m") will
instantiate a new ControllerContext. This doesn't need to be the case,
and upon reflection, it probably shouldn't.
Unless anyone can think of a problem with it, I'll save the existing
ControllerContext in the request attributes; all subsequent controllers
invoked in the chain will get the same Context.
One neat characteristic of this chaining process is that Controllers can
call ControllerContext.setParam() to define extra params to the view.
If the view results in another maverick invocation, those params are
passed to the Controller - the default behavior for ThrowawayBean2 and
FormBeanUser is to populate with the params, just like http request
params. This way, setParam() can be used to effectively override the
request parameters.
I'm a little puzzled by the original use case. The good news is that it
sounds like our chaining approach is exactly what you're looking for:
> - User signs guestbook form
> - signGuestbook.m command is executed
> - signGuestbook command's Sign controller is called
> - Sign controller stores guestbook entry to db
> - Sign controller returns SUCCESS
> - SUCCESS maps to another command -
> retrieveEntries (in this case not a view)
> - retrieveEntries.m command is executed
> - retrieveEntries command's Retrieve controller is called
> - Retrieve controller get's guestbook entries from database
> - Retrieve controller returns SUCCESS
> - SUCCESS maps to a view
> - View is displayed to User
...but this seems like the kind of place where you would _want_ a client
redirect. Otherwise the URL is going to be left in an ugly state.
Also, a client redirect will reduce the likelihood of double-posting.
BTW, there is yet another way of chaining controllers together in
Maverick. It is possible to write a custom View for Maverick that does
the chaining. So you could have a snippet of config like this:
<command name="chainedCommand">
<controller class="com.foo.A"/>
<view name="error" path="erra.jsp"/>
<view name="success" type="chain">
<controller class="com.foo.B"/>
<view name="error" path="errb.jsp"/>
<view name="success" path="b.jsp"/>
</view>
</command>
...but I'm not sure this buys you anything more than the approach Jim
mentioned (combined with the patch that I will apply tonight to keep the
context persistent :)
I'm actually interested in hearing more about the use cases that drive
the need for this; I've never had a desire to do this in my web
applications.
Jeff Schnitzer
[EMAIL PROTECTED]
> From: jim moore [mailto:[EMAIL PROTECTED]]
> > From: "Aapo Laakkonen" <[EMAIL PROTECTED]>
>
> > > no--"redirect" views use client side redirection.
> > > "document" views basically use a RequestDispatcher
> > > include so it is all server-side.
> >
> > Ok. Can you answer these?
> >
> > How is model constructed?
>
> That is up to you. The model gets set by calling
> ControllerContext.setModel(Object o) (All controllers have access to
the
> ControllerContext). If you extend one of the Throwaways, the default
is to
> set the controller itself as the model, though you can override this
by
> calling setModel yourself.
>
> >
> > - Does later commands override previous model and does
> > it have sama or different context?
>
> yes--each command would override the model set by the previous
command,
> however, each of the later commands should have access to the model
> created
> by the previous command, so controller 2 could take the model created
by
> controller 1 and add it to its own model.
>
> >
> > How the parameters (HTTP GET/POST) are passed to commands in a
chain?
> > - Every parameter is copied to every command if it
> > has specified property in a form bean or controller?
> > - Parameters are only passed to the first command?
> > - Can command that are prior other commands change
> > the parameters?
>
> Request parameters are immutable, so each command would receive
whatever
> parameters were passed in from the client exactly as they were
sent--i.e.
> no, controllers cannot change the parameters. You could use request
> attributes (or the model) to pass data from one controller to a later
> controller in the chain.
>
> >
> > Something else... maybe I just test it myself, but thanks for the
> > answers!
> >
> >
>
> --jim
>
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:
> > With Great Power, Comes Great Responsibility
> > Learn to use your power at OSDN's High Performance Computing Channel
> > http://hpc.devchannel.org/
> > [INVALID FOOTER]
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> [INVALID FOOTER]
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
[INVALID FOOTER]
