Note that I was thinking more about request parameters than
request-scoped objects.. not really the same thing :-)

Bye
Cosma

2006/6/23, Cosma Colanicchia <[EMAIL PROTECTED]>:
I had in mind something like this:

<navigation-rule>
  <from-view-id>*</from-view-id>
  <navigation-case>
    <from-outcome>gotoEditPerson</from-outcome>
    <to-view-id>/person/edit.jspx(personId)</to-view-id>
  <navigation-case>
</navigation-rule>

See the <to-view-id>: that view declares that it "wants" a personId
parameter. The place where this syntax should be interpreted is the
NavigationHandler, which is also the place where redirection caused by
<redirect/> tag is executed.. this way the NavigationHandler could
"save" only the parameters that the destination page declare to accept
(it could of course save other objects not declared like the locale).

Maybe I'm obsessed with strong type checking, but I'd really like
having my views declaring their interface (input parameters).. :-)

Ciao
Cosma



2006/6/23, Mario Ivankovits <[EMAIL PROTECTED]>:
> Hi!
> > It would be better to have a context initialization parameter to
> > enable this behaviour.. sometimes it is "expected" to drop request
> > scoped stuff on redirects :).
> Yes, when I add the "number of redirects" configuration I'll add this too.
>
> > BTW, nice idea..
> Thanks!
>
> > Some days ago I was thinking about something similar but "selective",
> > with an extended navigation rule syntax allowing views to declare the
> > objects to persist.
> Hmmmm .... what I can do is to allow to configure something like a
> TrackRedirectInterface with a method like "int trackRedirect(....)"
> where one can return a bit combination (or something simmilar) to tell
> the RedirectTracker which information to save. e.g. even if you drop
> your beans, you will keep the messages.
>
>
> Thanks for your input!
>
> Ciao,
> Mario
>
>

Reply via email to