cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject Re: AW: [C2]: ToDo - List for going Beta
Date Thu, 12 Apr 2001 13:18:11 GMT
At 2:07 PM +0200 12/4/01, Carsten Ziegeler wrote:
>> > 2. Cleaning up the environment
>> >    We had the recent discussion about the sendRedirect() method of the
>> >    Response object (same applies to the getRealPath() of the Context).
>> >    The discussion about sendRedirect() showed, that most of us agreed
>> >    to remove it from the Request object. But the main problem then
>> >    would be porting existing applications from C1 to C2. If we leave
>> >    sendRedirect() only for porting reasion, everybody will use it, and
>> >    we have no chance to remove it at a later time.
>> >    My suggestion is to remove the sendRedirect() from the Request. For
>> >    porting reasion the HttpRequest still contains the sendRedirect(),
>> >    thus casting the Request to the HttpRequest will allow the call
>> >    the method. This will only work in the http environment, but for me
>> >    this sounds reasonable for a fast migration.
>> >    There are others methods in the environment which should be removed
>> >    for same reasons as the sendRedirect().
>> >    If we agree on this, I will volunteer for it.
>>
>> We have to take the following into acount for redirect:
>>
>> 1. If the pipeline has started to output characters onto the
>>    OutputStream IIRC the servlet engine will throw an Exception
>>    when issuing a redirect afterwards. There will be situation where you
>>    *never* will be able to redirect because of this restriction (think
>>    of a pipeline containing a XSP generator and an XMLSerializer which
>>    almost immediately produce output on the OutputStream).
>>
>> 2. If we allow redirects we then need a way to report that (probabbly by
>>    an Exception) to the pipeline from a sitemap component that a
>>    redirection has occurred to interrupt the resource production because
>>    it will throw an Exception otherwise.
>>
>Yes, I think, this is another reason for officially removing sendRedirect().
>If really the only problem with sendRedirect() is migrating projects, we
>could (and will) offer help on the migration.

This is a really nice offer, but it is slightly more complicated ....

The issue as it effects me is that if redirection is available, then the
authoring language that we use to build webApps (the Crudlet.org TagLib)
will contain the concept of redirection. If redirection was not available,
the language would have been designed quite differently.

I am at the stage where I am about to re-implement the language Crudlet.org
2.0, this has been in specification for a while. Now I know that
redirection is not going to be available in C2 from the TagLib level, I
have the chance to hopefully re-design certain aspects of the language so
then used in C1, it will use the response taglib for re-direction, while in
C2 that will be mapped in the sitemap.

Problem is, I understand so little about the capabilities of the Sitemap at
this stage.

I would love to have a discussion to help me understand the correct way of
implementing the Crudlet webApp, but don't want to drag you away from the
amazing work that you are doing!


regards Jeremy



-- 
   ___________________________________________________________________

   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

   <mailto:sharkbait@mac.com>     		 <http://www.media.demon.co.uk>
    <phone:+44.[0].20.7737.6831>        <pager:jermq@sms.genie.co.uk>

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


Mime
View raw message