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/18 14:44:18 UTC
AW: cvs commit: xml-cocoon/webapp/docs/samples/xsp cookie.xsp
Hi!
This is the final step for being independent of the javax.servlet classes.
I added the Cookie and Session class to the environment. Both have nearly
the same functionality than their servlet pendants.
I also cleaned up the environment by removing some of the methods in the
Request und Response objects, mainly (--and please don't kill me now--)
the sendRedirect method and some other methods for manipulating the response
output. (For the first initial test, I only commented the sendRedirect etc out...)
For a working version I had to change the Reader and the Environment interface to
allow setting of the content length. The ResourceReader still contains a link
to the javax.servlet classes. This must still be removed.
Another problem is the servlet api 2.3 - it changed the build.xml script. For both
servlet apis (2.2 and 2.3) the same request and response classes are used as
the environment.Request/Response methods don't use special servlet methods.
Thus we could remove (except for the wrapper class) the difference between
both servlet apis.
So lets see if we all can live with this solution. Comments are welcome...
Carsten
Open Source Group sunShine - b:Integrated
================================================================
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: AW: cvs commit: xml-cocoon/webapp/docs/samples/xsp cookie.xsp
Posted by giacomo <gi...@apache.org>.
On Wed, 18 Apr 2001, Carsten Ziegeler wrote:
> Hi!
>
> This is the final step for being independent of the javax.servlet classes.
> I added the Cookie and Session class to the environment. Both have nearly
> the same functionality than their servlet pendants.
>
> I also cleaned up the environment by removing some of the methods in the
> Request und Response objects, mainly (--and please don't kill me now--)
> the sendRedirect method and some other methods for manipulating the response
> output. (For the first initial test, I only commented the sendRedirect etc out...)
Cool work ;)
> For a working version I had to change the Reader and the Environment interface to
> allow setting of the content length. The ResourceReader still contains a link
> to the javax.servlet classes. This must still be removed.
One thing I remember was getting the mime-type from the servlet engine
but I think this can be wrapped as well (haven't looked into the code)
> Another problem is the servlet api 2.3 - it changed the build.xml script. For both
> servlet apis (2.2 and 2.3) the same request and response classes are used as
> the environment.Request/Response methods don't use special servlet methods.
> Thus we could remove (except for the wrapper class) the difference between
> both servlet apis.
IIRC the spec 2.3 states that one *must* use the wrapper classes to wrap
Request/Response objects. In a early stage of Catalina some
functionallity wasn't available if the wrappers were not used.
> So lets see if we all can live with this solution. Comments are welcome...
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: Script Action
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Jason Foster wrote:
>
> I'm not sure how well this fits in with the current discussions but here
> goes...
>
> Actions seem to be on the way to becoming a dominant player in the
> Cocoon-as-WebApp arena. There has already been some concern about what
> appear to be tight linkages between Actions and Java and how that could
> restrict developers.
>
> Would a ScriptAction, that leverages the BSF much like the
> ScriptGenerator,
> be of use? Actions could then be implemented in any BSF-aware language.
>
> Just a thought.
>
This might be a could thought! The only problem which prevented me some
weeks ago from implementing it is the conversation between the script
and the action: The action returns a Map object which must then
be provided in any way by the script.
Carsten
> Jason Foster
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Script Action
Posted by giacomo <gi...@apache.org>.
On Wed, 18 Apr 2001, Jason Foster wrote:
> I'm not sure how well this fits in with the current discussions but here
> goes...
>
> Actions seem to be on the way to becoming a dominant player in the
> Cocoon-as-WebApp arena. There has already been some concern about what
> appear to be tight linkages between Actions and Java and how that could
> restrict developers.
>
> Would a ScriptAction, that leverages the BSF much like the ScriptGenerator,
> be of use? Actions could then be implemented in any BSF-aware language.
Whats the benefit beside using a scripting language?
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Script Action
Posted by Jason Foster <ja...@engmail.uwaterloo.ca>.
I'm not sure how well this fits in with the current discussions but here
goes...
Actions seem to be on the way to becoming a dominant player in the
Cocoon-as-WebApp arena. There has already been some concern about what
appear to be tight linkages between Actions and Java and how that could
restrict developers.
Would a ScriptAction, that leverages the BSF much like the ScriptGenerator,
be of use? Actions could then be implemented in any BSF-aware language.
Just a thought.
Jason Foster
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: cvs commit: xml-cocoon/webapp/docs/samples/xsp cookie.xsp
Posted by Carsten Ziegeler <cz...@sundn.de>.
What I did forget to tell you:
If you don't care about the environment you are currently running in
(commandline, servlet or whatever) and you know that you always use
the servlet environment (if you are comming from C1 then this might
be the case anyway), you can still use one trick:
You can cast the Response object to the org.apache.cocoon.environment.http.HttpResponse
object and use the old sendRedirect() method. But this only works with servlets!!
I know this a bad thing to do, but it might be another way for migrating.
Carsten
> Carsten Ziegeler wrote:
>
> Hi!
>
> This is the final step for being independent of the javax.servlet classes.
> I added the Cookie and Session class to the environment. Both have nearly
> the same functionality than their servlet pendants.
>
> I also cleaned up the environment by removing some of the methods in the
> Request und Response objects, mainly (--and please don't kill me now--)
> the sendRedirect method and some other methods for manipulating
> the response
> output. (For the first initial test, I only commented the
> sendRedirect etc out...)
>
> For a working version I had to change the Reader and the
> Environment interface to
> allow setting of the content length. The ResourceReader still
> contains a link
> to the javax.servlet classes. This must still be removed.
> Another problem is the servlet api 2.3 - it changed the build.xml
> script. For both
> servlet apis (2.2 and 2.3) the same request and response classes
> are used as
> the environment.Request/Response methods don't use special
> servlet methods.
> Thus we could remove (except for the wrapper class) the difference between
> both servlet apis.
>
> So lets see if we all can live with this solution. Comments are welcome...
>
> Carsten
>
> Open Source Group sunShine - b:Integrated
> ================================================================
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org