> Giacomo Pati wrote:
>
> On Wed, 6 Jun 2001, Berin Loritsch wrote:
>
> > giacomo wrote:
> > >
> > > On Tue, 5 Jun 2001, Davanum Srinivas wrote:
> > >
> > > > Giacomo,
> > > > Please check if what i checked in is ok.
> > >
> > > After thinking again we'd better extend the Environment
> interface with a
> > > method called getRedirector() as replacement for the redirect() method
> > > (similar to getOutputStream()) and let the sitemap engine pass that
> > > object to the Actions and of course use that for the implementation of
> > > the map:redirect element as well. It seams a clearer approach to me so
> > > implementors of an Environment are free how to implement a Redirector.
>
> And here comes another way to do it:
>
> Let the sitemap have its own Redirector implementation which proxies the
> Environments redirect method. This way the Environment interface doesn't
> have to be changed and the sitemap can track redirection to break out of
> the evaluation loop as it does for <map:redirect uri=.../>
>
> What do you all think?
>
Yes, this might be the way to go. We don't have to change interfaces!
The current implementation has the problem that the evaluation loop
is not exited even when a redirect takes place in an action.
But I am not quite sure how the sitemap can "remember" the state for one
single request if it has done a redirect or not.
But anyway, the current implementation should be changed as now is
assumed that the Environment always implements the Redirector interface
which is not true for the command line interface...
Carsten
> Giacomo
>
> > >
> > > But anyway, thanks for the quick solution :)
> > >
> > > Giacomo
> > >
> > > >
> > > > Berin,
> > > > Please let me know if this works for you.
> > > >
> > > > Thanks,
> > > > dims
> > > >
> > > > --- giacomo <[EMAIL PROTECTED]> wrote:
> > > > > On Tue, 5 Jun 2001, Berin Loritsch wrote:
> > > > >
> > > > > > There is one point in the webapp that makes WebApp developing
> > > > > > more difficult than necessary in Cocoon2. This has to do with
> > > > > > redirects. I was originally for not allowing redirects for
> > > > > > generators, transformers, and especially serializers. However,
> > > > > > I always tried to advocate leaving that ability in Actions.
> > > > > > As a result, we have our Sitemap handle too many concerns.
> > > > > > NEVER should the sitemap handle WebApp LOGIC. I don't mind
> > > > > > having it specify the Actions to use, or even rearrange their
> > > > > > order. I do mind that I have to do some serious fenangling
> > > > > > with sitemap parameters and dynamic logic to embed program
> > > > > > logic in the sitemap.
> > > > > >
> > > > > > I propose to allow the Environment object to be passed to
> > > > > > Actions in the objectModel. That way, Actions can still do
> > > > > > redirects--easing program development. This also simplifies
> > > > > > the site administrators duties in that they no longer have
> > > > > > to know the gory details of how the program logic works.
> > > > > > All the time, it also removes the ability for the other
> > > > > > sitemap components to perform redirects.
> > > > > >
> > > > > > The current programming model is too restrictive--and I have
> > > > > > to do true HACKS to get around it. I have a program to
> > > > > > release to a customer soon, and it would really simplify my
> > > > > > life if I can handle site security and redirects conveniently
> > > > > > in Actions.
> > > > >
> > > > > I knew it will come sooner or later. Maybe we should have
> a Redirector
> > > > > interface that a concrete Environment should implement to
> enable an
> > > > > Action to do redirects only (I don't see the other methods of
> > > > > the Environment interface be relevant to an Action).
> > > > >
> > > > > As this is a change of an Interface (Action) this should be
> > > > > implemented VERY SOON as Carsten will do the dists tomorrow.
> > > > >
> >
> > Technically we could do this, as no CLIENT programming uses the
> Environment.
> > That is the sole realm of the Processors (AKA Cocoon and Sitemap).
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
