You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@sundn.de> on 2001/04/09 14:09:54 UTC
[C2]: Request/Response cleanup?
Hi,
regarding the current Request/Response objects of the environment,
they are still some problems to fix:
1. They still depend on the javax.servlet package.
This is caused by the usage of the javax.servlet.http.HttpSession
and the javax.servlet.http.Cookie objects.
We could remove these dependencies by creating one classes for
Session and Cookie, like we did for the Response and the Request.
I think this makes sense for the Session, but I am not sure
about Cookie as not every environment will support cookies.
2. Some methods should not be allowed resp. might not available in
every environment.
We should remove the sendRedirect() method to avoid messing up
the output (as Stefano suggested).
Further, there might be method which only make sense with http
environment. How should we handle these?
What do you think about this?
Regards
Carsten
Open Source Group sunShine - Lighting up e:Business
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto:cziegeler@sundn.de
================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[RT C2]: Sitemap reloading
Posted by Carsten Ziegeler <cz...@sundn.de>.
Just a little random thought about sitemap reloading:
As I discovered last week, the cocoon-reload parameter does not
reload the sitemap but creates a new cocoon instance, which
might in turn reload the sitemap.
This parameter is only allowed:
a) for requesting the context itself, like http://localhost/cocoon
b) if the servlet is configured to allow these reloads (default
is yes)
I think this approach is OK, but I am currently missing a feature
called synchron sitemap reloading: There are often situations
where you change the sitemap and want to immediately test it.
As the sitemap is generated asynchron on the next effect, you
are wondering yourself what you did, as you don't see the
effect you expected (and believe me, you always forget that
the sitemap is generated asynchron until the next time...).
Now you have two choices:
a) creating a new cocoon instance, like explained above. This has
two disadvantages. First: you don't want a new cocoon instance,
but only the sitemap changes to take effect and second: you
have to send two request (http://localhost/cocoon?cocoon-reload=true
and http://localhost/cocoon/test).
b) Poll your new resource by sending repeatedly http://lolalhost/cocoon/test
until you see your changes. This has a main disadvantage: You don't know
when the new sitemap is used and if you get an error message, this might
indicate, that you're still using the old sitemap or that your new sitemap
is not correct.
So what I think is really very useful is forcing a synchron sitemap
reloading (if the sitemap changed), like http://localhost/test?cocoon-reloadsitemap=true.
What is your opinion on this?
Regards
Carsten
Open Source Group sunShine - Lighting up e:Business
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto:cziegeler@sundn.de
================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Request/Response cleanup?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Jeremy Quinn a écrit :
>
> At 11:23 PM +0200 9/4/01, giacomo wrote:
> >I haven't got into it but I think if you were restrictive in
> >implementing methods used to compile C2, we will probabbly hear what is
> >missing sooner or later this month like the sendRedirect. I don't see
> >any real reason at the moment to have sendRedirect in C2. But maybe
> >someone can explain a situation where you need a programatic redirect.
> >
> >Giacomo
>
> Porting existing Cocoon 1 Tag Libraries to Cocoon 2.
>
> I feel that the WebApp capabilities of Cocoon 2 are going to be amazing,
> but will take some while for all the pieces to fall into place, for good
> working patterns to disseminate, for people to un-learn Cocoon 1 patterns.
>
> In the meantime, pragmatically, it would be a nuisance if TagLibs were not
> able to trigger redirects.
>
> Why place extra barriers, especially at this stage, to people wanting to
> port to Cocoon 2?
>
> regards Jeremy
> --
> ___________________________________________________________________
>
> Jeremy Quinn Karma Divers
> webSpace Design
> HyperMedia Research Centre
>
> <ma...@mac.com> <http://www.media.demon.co.uk>
> <phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
>
Same for us : we plan to port our existing applications to Cocoon2,
which will be a matter of days with sendRedirect (minor changes in the
logicsheets and changing XObject to XMLFragment). But without
sendRedirect, this will lead to big changes and their cost will probably
forbid the port of these apps.
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Request/Response cleanup?
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Jeremy Quinn <je...@media.demon.co.uk>:
> At 11:23 PM +0200 9/4/01, giacomo wrote:
> >I haven't got into it but I think if you were restrictive in
> >implementing methods used to compile C2, we will probabbly hear what is
> >missing sooner or later this month like the sendRedirect. I don't see
> >any real reason at the moment to have sendRedirect in C2. But maybe
> >someone can explain a situation where you need a programatic redirect.
> >
> >Giacomo
>
> Porting existing Cocoon 1 Tag Libraries to Cocoon 2.
>
> I feel that the WebApp capabilities of Cocoon 2 are going to be amazing,
> but will take some while for all the pieces to fall into place, for good
> working patterns to disseminate, for people to un-learn Cocoon 1
> patterns.
>
> In the meantime, pragmatically, it would be a nuisance if TagLibs were
> not
> able to trigger redirects.
>
> Why place extra barriers, especially at this stage, to people wanting to
> port to Cocoon 2?
i can understand your point and I hope you understand mine :)
If we came to the conclusion that the redirect pattern in a Component should be
avoided but we leave it in the implementation than people will use it and wont
follow the right path to make it.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Request/Response cleanup?
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 11:23 PM +0200 9/4/01, giacomo wrote:
>I haven't got into it but I think if you were restrictive in
>implementing methods used to compile C2, we will probabbly hear what is
>missing sooner or later this month like the sendRedirect. I don't see
>any real reason at the moment to have sendRedirect in C2. But maybe
>someone can explain a situation where you need a programatic redirect.
>
>Giacomo
Porting existing Cocoon 1 Tag Libraries to Cocoon 2.
I feel that the WebApp capabilities of Cocoon 2 are going to be amazing,
but will take some while for all the pieces to fall into place, for good
working patterns to disseminate, for people to un-learn Cocoon 1 patterns.
In the meantime, pragmatically, it would be a nuisance if TagLibs were not
able to trigger redirects.
Why place extra barriers, especially at this stage, to people wanting to
port to Cocoon 2?
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Request/Response cleanup?
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Donald Ball wrote:
>
> On Mon, 9 Apr 2001, Colin Britton wrote:
>
> > I don't see
> > > any real reason at the moment to have sendRedirect in C2. But maybe
> > > someone can explain a situation where you need a programatic redirect.
> >
> > We use sendRedirect heavily for bouncing people off a cocoon
> enabled site to
> > other external resouces. This allows us to centrally manage
> (and control)
> > the information we are serving. This is a common thing to do,
> make sure that
> > the users browser redirects off a central server even when they getting
> > content from a satelite (or third party site). The sitemap
> along with an XSP
> > script makes a good url redirector!
>
> what he said. sure, you can do redirects from the sitemap, but it's nice
> to be able to do them from xsp pages or another sitemap component.
>
As far as I know, there was a discussion about this several month ago in
this mailing list - I hadn't time to search for it.
But I think I remember that it was Stefano who said, that "messing up
the output stream" must be forbidden. So only the environment should be
able to use redirects but not any sitemap component. I think that was
one of the reasons for passing only the objectModel to the sitemap
components and not the environment.
Of course, I agree, that doing sendRedirects from anywhere is very handy,
but is it really the clean solution? I don't know...
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [C2]: Request/Response cleanup?
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 5:10 PM +0200 10/4/01, Giacomo Pati wrote:
>Quoting Per Kreipke <pe...@onclave.com>:
>
>> Giacomo wrote:
>>
>> > There are other nice things _not_ in C2 because of some good reason.
>> > Why is redirection nice? What's the use case for rediretion inside
>> > components (includes XSP pages) ?
>>
>> Maybe I should be doing things differently, but here a couple of cases I
>> use
>> redirects for:
>>
>> - login: if the user accesses a restricted page before logging in, they
>> get
>> redirected to a login page. And of course back to the referrer when they
>> have successfully logged in.
>
>Well, I've always tried to convince people to use the servlet engine for
>authentication.
Nice, but often people need greater capabilities for authentication, our
users are stored in JavaSpaces for instance, the Servlet Spec does not have
plugable authenticators (unlike the TomCat implementation).
>but as you see below these things can be done with Actions.
This is all and well, but what do I do if I have to write a TagLib that
should work in both Cocoon 1 and 2 (because we need a smooth transition)?
[ snip ]
>> - validation: I use XSP in the controller to validate passwords and form
>> fields. Depending on their success, I redirect to different places.
>
>Same as above here for validation.
>
>It seems to me you followed truly Cocoon 1 pattern to solve your problems
>(mostly because there were no other ways to solve them) and this is IMHO
>not the
>way to go in Cocoon 2.
I agree, but if you force people to rewrite webApps from scratch, I suspect
it will slow down the Cocoon 2 adoption rate.
While I agree wholeheartedly with your desire to produce an ideal
environment, if you make it too difficult to port old work, imposing delay.
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [C2]: Request/Response cleanup?
Posted by Per Kreipke <pe...@onclave.com>.
Giacomo, Carsten,
> It seems to me you followed truly Cocoon 1 pattern to solve your problems
> (mostly because there were no other ways to solve them) and this
> is IMHO not the
> way to go in Cocoon 2.
I'm sorry, you are absolutely right, I was speaking of my current use in C1
but forgot to say so in my email. I am just beginning to port over to C2 and
wanted to let you know in response to your question what kind of design
patterns I thought C2 should support. And you've satisfied my concerns,
thanks. Will try to get the hang of the Actions next.
Per.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [C2]: Request/Response cleanup?
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Per Kreipke <pe...@onclave.com>:
> Giacomo wrote:
>
> > There are other nice things _not_ in C2 because of some good reason.
> > Why is redirection nice? What's the use case for rediretion inside
> > components (includes XSP pages) ?
>
> Maybe I should be doing things differently, but here a couple of cases I
> use
> redirects for:
>
> - login: if the user accesses a restricted page before logging in, they
> get
> redirected to a login page. And of course back to the referrer when they
> have successfully logged in.
Well, I've always tried to convince people to use the servlet engine for
authentication. but as you see below these things can be done with Actions.
> - private pages: if the users tries to access a 'private' (logged in,
> but no
> permissions to the page) page, they get redirected out of the hierarchy
> to
> prevent fishing around for content.
same here.
> - form handling: we try to use a MVC paradigm in our cocoon webapps.
> This
> implicitly uses redirects: the form posts to the controller which
> handles
> the post and redirects to the results or errors.
We've done that in an e-shop by use of custom Actions which controlls the flow
of the webapp by placeing the "next screen" in the returned Map of the Action
and refer to that entry in the sitemaps <map:generate> element.
> - validation: I use XSP in the controller to validate passwords and form
> fields. Depending on their success, I redirect to different places.
Same as above here for validation.
It seems to me you followed truly Cocoon 1 pattern to solve your problems
(mostly because there were no other ways to solve them) and this is IMHO not the
way to go in Cocoon 2.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Request/Response cleanup?
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Per Kreipke wrote:
>
> Giacomo wrote:
>
> > There are other nice things _not_ in C2 because of some good reason.
> > Why is redirection nice? What's the use case for rediretion inside
> > components (includes XSP pages) ?
>
> Maybe I should be doing things differently, but here a couple of
> cases I use
> redirects for:
>
> - login: if the user accesses a restricted page before logging
> in, they get
> redirected to a login page. And of course back to the referrer when they
> have successfully logged in.
>
> - private pages: if the users tries to access a 'private' (logged
> in, but no
> permissions to the page) page, they get redirected out of the hierarchy to
> prevent fishing around for content.
>
> - form handling: we try to use a MVC paradigm in our cocoon webapps. This
> implicitly uses redirects: the form posts to the controller which handles
> the post and redirects to the results or errors.
>
> - validation: I use XSP in the controller to validate passwords and form
> fields. Depending on their success, I redirect to different places.
>
> If these are covered using the sitemap redirector, great. If not, not so
> good.
>
We have build components with equal features, all of them are Actions which
work like the way Giacomo suggested earlier in this thread.
I personally don't like the redirects in the xsp pages (or in any other
sitemap component) as the these components build the *content* for the
request and therefore should not contain any application flow logic.
The sitemap is the place for the flow logic.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [C2]: Request/Response cleanup?
Posted by Per Kreipke <pe...@onclave.com>.
Giacomo wrote:
> There are other nice things _not_ in C2 because of some good reason.
> Why is redirection nice? What's the use case for rediretion inside
> components (includes XSP pages) ?
Maybe I should be doing things differently, but here a couple of cases I use
redirects for:
- login: if the user accesses a restricted page before logging in, they get
redirected to a login page. And of course back to the referrer when they
have successfully logged in.
- private pages: if the users tries to access a 'private' (logged in, but no
permissions to the page) page, they get redirected out of the hierarchy to
prevent fishing around for content.
- form handling: we try to use a MVC paradigm in our cocoon webapps. This
implicitly uses redirects: the form posts to the controller which handles
the post and redirects to the results or errors.
- validation: I use XSP in the controller to validate passwords and form
fields. Depending on their success, I redirect to different places.
If these are covered using the sitemap redirector, great. If not, not so
good.
Per Kreipke
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Request/Response cleanup?
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 10 Apr 2001, Giacomo Pati wrote:
> > okay. suppose i want to send the user to a URL i have pulled from a
> > database? it should not be the case that i have to declare every URL to
> > which i can redirect in the sitemap. i suppose one could write a match
> > rule like this:
> >
> > <map:match pattern="/redirect?url=*">
> > <map:redirect-to url="{$1}"/>
> > </map:match>
> >
> > and do it that way. but i can't see why it would be better that way than
> > by using a sendRedirect method. it will certainly make people complain.
>
> Because the sendRedirect method does not accomplish the model of sub
> pipelines. In a sub pipeline you might have a different context than
> the context of the cocoon servlet. The sitemap is telling the
> Environment object to enter a new context depending on <map:mount>
> elements but a component should think it is always at the top of a
> context (SoC I think).
uh, you're thinking of the sendRedirect method from the
HttpServletResponse object. our Response object could do something totally
different when sendRedirect is called on it.
> But anyway your proposed sitemap snippet shows how to do it. Maybe a correct
> implementation will use an Action to determine the redirection URI like this:
>
> <map:match pattern="/redirect">
> <map:act type="redirector">
> <map:redirect-to url="{$redirection-uri}"/>
> </map:act>
> </map:match>
i still don't see why that's any cleaner than providing a sendRedirect
method. how would a sitemap component or xsp page actually go about
sending a redirect based on some runtime condition using this methodology?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: Request/Response cleanup?
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 9:54 AM +0200 10/4/01, Carsten Ziegeler wrote:
>I think the main advantage of only using the sitemap for redirects
>is the visibility and the definition of the application flow.
>By looking at the sitemap you can see what is really happening if
>you send a particular request.
>The development of web applications is much simpler because you
>can define the flow completely in the sitemap and nowhere else.
>If you would have any redirect at another place (inside xsp
>or inside a transformer) this is not visible.
I completely agree, we should be recommending the best way of working in
the architecture of Cocoon 2.
However IMHO it is one thing to avoid adding _new_ stuff to Cocoon that
breaks SoC (my LogicTagLib proposal come to mind ;) but quite another to
remove a useful existing capability just for abstract purity, when it is
going to possibly slow down the porting of existing components to Cocoon 2.
For example, while writing the Crudlet TagLib for Cocoon 1, I had to
provide a complete WebApp language, that amongst other things makes quite a
lot of use of redirection, legitimately so I believe (there is often no
option in Cocoon 1).
When I port Crudlet to Cocoon 2 (with no redirect) I would have to
re-design the language far more than I would have to if redirect existed,
while what would be easier for existing Crudlet users could be gradual
evolution of the component to ideal Cocoon 2 patterns as they are developed.
Yes, when we have (and understand ;) flowmaps and all those other goodies
for making WebApps then I would very happily do without response
redirection.
But until then, please, leave it in!
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Request/Response cleanup?
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Giacomo Pati:
> Quoting Donald Ball <ba...@webslingerZ.com>:
>
> > On Tue, 10 Apr 2001, giacomo wrote:
> >
> > > > > I don't see
> > > > > > any real reason at the moment to have sendRedirect in C2. But
> > maybe
> > > > > > someone can explain a situation where you need a programatic
> > redirect.
> > > > >
> > > > > We use sendRedirect heavily for bouncing people off a cocoon
> > enabled site to
> > > > > other external resouces. This allows us to centrally manage (and
> > control)
> > > > > the information we are serving. This is a common thing to do, make
> > sure that
> > > > > the users browser redirects off a central server even when they
> > getting
> > > > > content from a satelite (or third party site). The sitemap along
> > with an XSP
> > > > > script makes a good url redirector!
> > > >
> > > > what he said. sure, you can do redirects from the sitemap, but it's
> > nice
> > > > to be able to do them from xsp pages or another sitemap component.
> > >
> > > There are other nice things _not_ in C2 because of some good reason.
> > > Why is redirection nice? What's the use case for rediretion inside
> > > components (includes XSP pages) ?
> >
> > okay. suppose i want to send the user to a URL i have pulled from a
> > database? it should not be the case that i have to declare every URL to
> > which i can redirect in the sitemap. i suppose one could write a match
> > rule like this:
> >
> > <map:match pattern="/redirect?url=*">
> > <map:redirect-to url="{$1}"/>
> > </map:match>
> >
> > and do it that way. but i can't see why it would be better that way than
> > by using a sendRedirect method. it will certainly make people complain.
>
> Because the sendRedirect method does not accomplish the model of
> sub pipelines.
> In a sub pipeline you might have a different context than the
> context of the
> cocoon servlet. The sitemap is telling the Environment object to
> enter a new
> context depending on <map:mount> elements but a component should
> think it is
> always at the top of a context (SoC I think).
>
> But anyway your proposed sitemap snippet shows how to do it.
> Maybe a correct
> implementation will use an Action to determine the redirection
> URI like this:
>
> <map:match pattern="/redirect">
> <map:act type="redirector">
> <map:redirect-to url="{$redirection-uri}"/>
> </map:act>
> </map:match>
>
I think the main advantage of only using the sitemap for redirects
is the visibility and the definition of the application flow.
By looking at the sitemap you can see what is really happening if
you send a particular request.
The development of web applications is much simpler because you
can define the flow completely in the sitemap and nowhere else.
If you would have any redirect at another place (inside xsp
or inside a transformer) this is not visible.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Request/Response cleanup?
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Donald Ball <ba...@webslingerZ.com>:
> On Tue, 10 Apr 2001, giacomo wrote:
>
> > > > I don't see
> > > > > any real reason at the moment to have sendRedirect in C2. But
> maybe
> > > > > someone can explain a situation where you need a programatic
> redirect.
> > > >
> > > > We use sendRedirect heavily for bouncing people off a cocoon
> enabled site to
> > > > other external resouces. This allows us to centrally manage (and
> control)
> > > > the information we are serving. This is a common thing to do, make
> sure that
> > > > the users browser redirects off a central server even when they
> getting
> > > > content from a satelite (or third party site). The sitemap along
> with an XSP
> > > > script makes a good url redirector!
> > >
> > > what he said. sure, you can do redirects from the sitemap, but it's
> nice
> > > to be able to do them from xsp pages or another sitemap component.
> >
> > There are other nice things _not_ in C2 because of some good reason.
> > Why is redirection nice? What's the use case for rediretion inside
> > components (includes XSP pages) ?
>
> okay. suppose i want to send the user to a URL i have pulled from a
> database? it should not be the case that i have to declare every URL to
> which i can redirect in the sitemap. i suppose one could write a match
> rule like this:
>
> <map:match pattern="/redirect?url=*">
> <map:redirect-to url="{$1}"/>
> </map:match>
>
> and do it that way. but i can't see why it would be better that way than
> by using a sendRedirect method. it will certainly make people complain.
Because the sendRedirect method does not accomplish the model of sub pipelines.
In a sub pipeline you might have a different context than the context of the
cocoon servlet. The sitemap is telling the Environment object to enter a new
context depending on <map:mount> elements but a component should think it is
always at the top of a context (SoC I think).
But anyway your proposed sitemap snippet shows how to do it. Maybe a correct
implementation will use an Action to determine the redirection URI like this:
<map:match pattern="/redirect">
<map:act type="redirector">
<map:redirect-to url="{$redirection-uri}"/>
</map:act>
</map:match>
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Request/Response cleanup?
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 10 Apr 2001, giacomo wrote:
> > > I don't see
> > > > any real reason at the moment to have sendRedirect in C2. But maybe
> > > > someone can explain a situation where you need a programatic redirect.
> > >
> > > We use sendRedirect heavily for bouncing people off a cocoon enabled site to
> > > other external resouces. This allows us to centrally manage (and control)
> > > the information we are serving. This is a common thing to do, make sure that
> > > the users browser redirects off a central server even when they getting
> > > content from a satelite (or third party site). The sitemap along with an XSP
> > > script makes a good url redirector!
> >
> > what he said. sure, you can do redirects from the sitemap, but it's nice
> > to be able to do them from xsp pages or another sitemap component.
>
> There are other nice things _not_ in C2 because of some good reason.
> Why is redirection nice? What's the use case for rediretion inside
> components (includes XSP pages) ?
okay. suppose i want to send the user to a URL i have pulled from a
database? it should not be the case that i have to declare every URL to
which i can redirect in the sitemap. i suppose one could write a match
rule like this:
<map:match pattern="/redirect?url=*">
<map:redirect-to url="{$1}"/>
</map:match>
and do it that way. but i can't see why it would be better that way than
by using a sendRedirect method. it will certainly make people complain.
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Request/Response cleanup?
Posted by giacomo <gi...@apache.org>.
On Mon, 9 Apr 2001, Donald Ball wrote:
> On Mon, 9 Apr 2001, Colin Britton wrote:
>
> > I don't see
> > > any real reason at the moment to have sendRedirect in C2. But maybe
> > > someone can explain a situation where you need a programatic redirect.
> >
> > We use sendRedirect heavily for bouncing people off a cocoon enabled site to
> > other external resouces. This allows us to centrally manage (and control)
> > the information we are serving. This is a common thing to do, make sure that
> > the users browser redirects off a central server even when they getting
> > content from a satelite (or third party site). The sitemap along with an XSP
> > script makes a good url redirector!
>
> what he said. sure, you can do redirects from the sitemap, but it's nice
> to be able to do them from xsp pages or another sitemap component.
There are other nice things _not_ in C2 because of some good reason.
Why is redirection nice? What's the use case for rediretion inside
components (includes XSP pages) ?
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Request/Response cleanup?
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 9 Apr 2001, Colin Britton wrote:
> I don't see
> > any real reason at the moment to have sendRedirect in C2. But maybe
> > someone can explain a situation where you need a programatic redirect.
>
> We use sendRedirect heavily for bouncing people off a cocoon enabled site to
> other external resouces. This allows us to centrally manage (and control)
> the information we are serving. This is a common thing to do, make sure that
> the users browser redirects off a central server even when they getting
> content from a satelite (or third party site). The sitemap along with an XSP
> script makes a good url redirector!
what he said. sure, you can do redirects from the sitemap, but it's nice
to be able to do them from xsp pages or another sitemap component.
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Request/Response cleanup?
Posted by giacomo <gi...@apache.org>.
On Mon, 9 Apr 2001, Colin Britton wrote:
> I don't see
> > any real reason at the moment to have sendRedirect in C2. But maybe
> > someone can explain a situation where you need a programatic redirect.
> >
>
> We use sendRedirect heavily for bouncing people off a cocoon enabled site to
> other external resouces. This allows us to centrally manage (and control)
> the information we are serving. This is a common thing to do, make sure that
> the users browser redirects off a central server even when they getting
> content from a satelite (or third party site). The sitemap along with an XSP
> script makes a good url redirector!
I assume you're using Cocoon 2. Did you ever thought of doing it with
the sitemap capability <map:redirect-to uri=...>?
If that is not enought for you can you tell us why?
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Request/Response cleanup?
Posted by Colin Britton <cb...@centervilletech.com>.
I don't see
> any real reason at the moment to have sendRedirect in C2. But maybe
> someone can explain a situation where you need a programatic redirect.
>
We use sendRedirect heavily for bouncing people off a cocoon enabled site to
other external resouces. This allows us to centrally manage (and control)
the information we are serving. This is a common thing to do, make sure that
the users browser redirects off a central server even when they getting
content from a satelite (or third party site). The sitemap along with an XSP
script makes a good url redirector!
rgds
CB
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Request/Response cleanup?
Posted by Colin Britton <cb...@centervilletech.com>.
I don't see
> any real reason at the moment to have sendRedirect in C2. But maybe
> someone can explain a situation where you need a programatic redirect.
>
We use sendRedirect heavily for bouncing people off a cocoon enabled site to
other external resouces. This allows us to centrally manage (and control)
the information we are serving. This is a common thing to do, make sure that
the users browser redirects off a central server even when they getting
content from a satelite (or third party site). The sitemap along with an XSP
script makes a good url redirector!
rgds
CB
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Request/Response cleanup?
Posted by giacomo <gi...@apache.org>.
On Mon, 9 Apr 2001, Davanum Srinivas wrote:
> Giacomo,
> Can you please review the Request/Response classes? (I went as far as getting everything to
> compile and run. But did not get into what should be added/removed/modified)
I haven't got into it but I think if you were restrictive in
implementing methods used to compile C2, we will probabbly hear what is
missing sooner or later this month like the sendRedirect. I don't see
any real reason at the moment to have sendRedirect in C2. But maybe
someone can explain a situation where you need a programatic redirect.
Giacomo
>
> Thanks,
> dims
>
> --- giacomo <gi...@apache.org> wrote:
> >
> >
> > On Mon, 9 Apr 2001, Davanum Srinivas wrote:
> >
> > > Donald,
> > >
> > > Please take a look at HttpEnvironment/AbstractCommandLineEnvironment/Enviroment.java files.
> > There
> > > is a redirect() method which should be used instead.
> >
> > Carefull, the Environment interface was made exclusively for the
> > sitemap classes not for components.
> >
> > Giacomo
> >
> > >
> > > Thanks,
> > > dims
> > >
> > > --- Donald Ball <ba...@webslingerZ.com> wrote:
> > > > On Mon, 9 Apr 2001, Davanum Srinivas wrote:
> > > >
> > > > > Regarding #2, Am ok (+1) with removing sendRedirect()
> > > >
> > > > woah - so what do our components do if they want to issue a redirect then?
> > > >
> > > > - donald
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > > >
> > >
> > >
> > > =====
> > > Davanum Srinivas, JNI-FAQ Manager
> > > http://www.jGuru.com/faq/JNI
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Get email at your own domain with Yahoo! Mail.
> > > http://personal.mail.yahoo.com/
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
>
>
> =====
> Davanum Srinivas, JNI-FAQ Manager
> http://www.jGuru.com/faq/JNI
>
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
>
> ---------------------------------------------------------------------
> 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
Re: [C2]: Request/Response cleanup?
Posted by Davanum Srinivas <di...@yahoo.com>.
Giacomo,
Can you please review the Request/Response classes? (I went as far as getting everything to
compile and run. But did not get into what should be added/removed/modified)
Thanks,
dims
--- giacomo <gi...@apache.org> wrote:
>
>
> On Mon, 9 Apr 2001, Davanum Srinivas wrote:
>
> > Donald,
> >
> > Please take a look at HttpEnvironment/AbstractCommandLineEnvironment/Enviroment.java files.
> There
> > is a redirect() method which should be used instead.
>
> Carefull, the Environment interface was made exclusively for the
> sitemap classes not for components.
>
> Giacomo
>
> >
> > Thanks,
> > dims
> >
> > --- Donald Ball <ba...@webslingerZ.com> wrote:
> > > On Mon, 9 Apr 2001, Davanum Srinivas wrote:
> > >
> > > > Regarding #2, Am ok (+1) with removing sendRedirect()
> > >
> > > woah - so what do our components do if they want to issue a redirect then?
> > >
> > > - donald
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> >
> >
> > =====
> > Davanum Srinivas, JNI-FAQ Manager
> > http://www.jGuru.com/faq/JNI
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get email at your own domain with Yahoo! Mail.
> > http://personal.mail.yahoo.com/
> >
> > ---------------------------------------------------------------------
> > 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
>
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Request/Response cleanup?
Posted by giacomo <gi...@apache.org>.
On Mon, 9 Apr 2001, Davanum Srinivas wrote:
> Donald,
>
> Please take a look at HttpEnvironment/AbstractCommandLineEnvironment/Enviroment.java files. There
> is a redirect() method which should be used instead.
Carefull, the Environment interface was made exclusively for the
sitemap classes not for components.
Giacomo
>
> Thanks,
> dims
>
> --- Donald Ball <ba...@webslingerZ.com> wrote:
> > On Mon, 9 Apr 2001, Davanum Srinivas wrote:
> >
> > > Regarding #2, Am ok (+1) with removing sendRedirect()
> >
> > woah - so what do our components do if they want to issue a redirect then?
> >
> > - donald
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
>
> =====
> Davanum Srinivas, JNI-FAQ Manager
> http://www.jGuru.com/faq/JNI
>
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
>
> ---------------------------------------------------------------------
> 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
Re: [C2]: Request/Response cleanup?
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 9 Apr 2001, Davanum Srinivas wrote:
> Please take a look at
> HttpEnvironment/AbstractCommandLineEnvironment/Enviroment.java files.
> There is a redirect() method which should be used instead.
score. we should probably throw together a table of information on how to
work with http environment stuff using the c2 abstracted layers.
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Request/Response cleanup?
Posted by Davanum Srinivas <di...@yahoo.com>.
Donald,
Please take a look at HttpEnvironment/AbstractCommandLineEnvironment/Enviroment.java files. There
is a redirect() method which should be used instead.
Thanks,
dims
--- Donald Ball <ba...@webslingerZ.com> wrote:
> On Mon, 9 Apr 2001, Davanum Srinivas wrote:
>
> > Regarding #2, Am ok (+1) with removing sendRedirect()
>
> woah - so what do our components do if they want to issue a redirect then?
>
> - donald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Request/Response cleanup?
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 9 Apr 2001, Davanum Srinivas wrote:
> Regarding #2, Am ok (+1) with removing sendRedirect()
woah - so what do our components do if they want to issue a redirect then?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Request/Response cleanup?
Posted by Davanum Srinivas <di...@yahoo.com>.
Carsten,
Regarding #1, I had an offline query from ""Colin Britton" <cb...@centervilletech.com>" about
"Cookie logicsheets". Colin mentioned that they have ported the Cookie Logicsheet from C1 to C2.
(But not to the latest Request/Response interface). Waz waiting to hear from him again....Before
fixing the Cookie / HttpSession dependencies. But, yes, please go ahead and add new classes to
wrap Cookie and Session.
Regarding #2, Am ok (+1) with removing sendRedirect()
Thanks,
dims
--- Carsten Ziegeler <cz...@sundn.de> wrote:
> Hi,
>
> regarding the current Request/Response objects of the environment,
> they are still some problems to fix:
> 1. They still depend on the javax.servlet package.
> This is caused by the usage of the javax.servlet.http.HttpSession
> and the javax.servlet.http.Cookie objects.
>
> We could remove these dependencies by creating one classes for
> Session and Cookie, like we did for the Response and the Request.
> I think this makes sense for the Session, but I am not sure
> about Cookie as not every environment will support cookies.
>
> 2. Some methods should not be allowed resp. might not available in
> every environment.
> We should remove the sendRedirect() method to avoid messing up
> the output (as Stefano suggested).
> Further, there might be method which only make sense with http
> environment. How should we handle these?
>
> What do you think about this?
>
>
> Regards
> Carsten
>
> Open Source Group sunShine - Lighting up e:Business
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto:cziegeler@sundn.de
> ================================================================
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org