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]
