While supporting the concept is important, I'm not personally convinced *yet* that controller chaining has enormous merit. So far I haven't seen a compelling need for it in my work. Certainly in the case of the friendbook logout, a redirect is fully appropriate in order to preserve the browser's ability to bookmark links.
Even if you wanted to provide a more sophisticated "bye" page instead of just sending the user back to the welcome page, it seems to me that you're best off putting the controller logic in the Logout class and forwarding to a normal "bye" view. But I'm open to different views - John-Mason Shackelford seems to be putting a lot of effort into the subject, and I'm curious to know how that goes :) Jeff Schnitzer [EMAIL PROTECTED] > -----Original Message----- > From: Eelco Hillenius [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 11, 2003 1:31 AM > To: [EMAIL PROTECTED] > Subject: Re: [Mav-user] server side redirects for commands > > Thanks for pointing that out Jeff, > > You are right about the difference between redirects and forwards > ofcourse, > and now that I took a closer look at the code, I understand the flow. I > was > just looking at the friendbook example and thought that using redirects > was > the way to link commands in Maverik fashion. Maybe it's a good idea to > adjust the friendbook example, so that the differences in usage (redirect/ > forward) become clear. This is currently in the friendbook example: > > <command name="logout"> > <controller class="org.infohazard.friendbook.ctl.Logout"/> > <view name="loginRequired" ref="loginRequired"/> > <view name="loginFailed" ref="loginFailed"/> > <view name="success" type="redirect" path="welcome.m"/> > </command> > > Instead something like this would clearify things: > > <command name="logout"> > <controller class="org.infohazard.friendbook.ctl.Logout"/> > <view name="loginRequired" ref="loginRequired"/> > <view name="loginFailed" ref="loginFailed"/> > > <!-- use a redirect (HTTP 302 response) > parameters set in the ControllerContext will be made available > to the view in the form of request parameters > Note that only string parameters will make sense > --> > <view name="success" type="redirect" path="welcome.m"/> > > <!-- if you want to do a forward (server side) you can use > > <view name="success" type="document" path="welcome.m"/> > > instead. Using this will save you a client server roundtrip, > and > you can use arbitrary objects as request parameters, > and you will have access to the model set by the last > command). > Note that if you access the model , and that model is a > command, > you create a dependency of commands and loose > the freedom freely linking commands without them knowing about > each other. If you use parameters in the ControllerContext, > or you use a common command-neutral model, you just have a > 'contract-like' dependency. > --> > > </command> > > I understand that you can do neat stuff with inheritance. On the other > hand, > I think it is nice to make commands (potentially) work together without > requiring them to use a common base class. A contract (command requires > certain variables to be available) couples loosely. But, hey... the nice > thing about Maverik is that you can decide yourself! > > Thanks for the quick response, > > Eelco Hillenius > > > ----- Original Message ----- > From: "Schnitzer, Jeff" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, February 11, 2003 2:24 AM > Subject: RE: [Mav-user] server side redirects for commands > > > The word you are looking for is a "forward", not a "redirect". > Redirects are inherently client-side phenomenon; they are the result of > an HTTP 302 response. > > Inside the server, you forward from one request to another. In fact, > this is how Maverick executes JSPs (or other "documents") - using the > forward mechanism. > > Try this: > > <view name="simpleReport" type="document" path="showSimpleReport.m"/> > > This "chains" the first command to the second. Any params are persisted > across the invocation... and if you're careful about your controller > base class, you can get access to the model as well. > > Jeff Schnitzer > [EMAIL PROTECTED] > > > -----Original Message----- > > From: Eelco Hillenius [mailto:[EMAIL PROTECTED]] > > Sent: Monday, February 10, 2003 2:40 PM > > To: [EMAIL PROTECTED] > > Subject: [Mav-user] server side redirects for commands > > > > Hi all, > > > > Say, I have got a view like: > > <view name="simpleReport" type="redirect" path="showSimpleReport.m"/> > (I > > use > > .m for Maverik commands). The current version of Maverik does a normal > > redirect (response.sendRedirect). Imho it would be great if Maverik > would > > recognize that it is about to redirect to another Maverik command, and > > instead of doing a real redirect, call that other command. And instead > of > > making a string copy of the objects in the context (stored like > > getCtx().setParam(blah, obj)) to request parameters, make (or keep) > the > > objects available in their original form. > > > > I have got the case that I want to do a redirect to another command. > For > > this other command I have some object (which is not of type string!) > > available in my first/ calling command. Right now the only way that I > can > > expose arbitrary objects from the first command to the second command > is > > by > > using session objects (or something similar), which is not *that* > handy. > > > > Besides my own little problem (I already implemented the workaround), > I > > think doing a 'server side' redirect is better because it saves a > > client-server roundtrip. Better because it it more efficient, and > because > > it > > does not expose variables meant for internal use (which is allways the > > case > > if command1 calls command2?). > > > > Well, what do you all think? > > > > Cheers, > > > > Eelco Hillenius > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > http://www.vasoftware.com > > [INVALID FOOTER] > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! > http://www.vasoftware.com > [INVALID FOOTER] > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > [INVALID FOOTER] ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com [INVALID FOOTER]
