Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Wed, 6 Jun 2001 22:04:45 +0200 (CEST)
From: giacomo <giacomo@apache.org>
To: <cocoon-dev@xml.apache.org>
Subject: Re: Why WebApp programming is harder than necessary with C2
In-Reply-To: <3B1E2A23.DB906A7A@apache.org>
Message-ID: <Pine.LNX.4.31.0106062201120.4534-100000@lap1.otego.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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?

Giacomo

> >
> > But anyway, thanks for the quick solution :)
> >
> > Giacomo
> >
> > >
> > > Berin,
> > > Please let me know if this works for you.
> > >
> > > Thanks,
> > > dims
> > >
> > > --- giacomo <giacomo@apache.org> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org