cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett McLaughlin <>
Subject [Fwd: Examples and wrappers for Cocoon (from other applications)]
Date Wed, 22 Dec 1999 13:39:16 GMT
Brett McLaughlin wrote:
I'm sorry guys, some one let me know I was being an idiot yesterday and
sent class files for the examples, not .java files.  My bad.. (need ....
coffee .... )  Here they are.


> Stefano & Co.-
>         More files attached.  I still don't know how to do a cvs diff with a
> new file, so this is just the file, I guess drop it in your IDE and add
> it in to CVS that way.
> There are three files:
> 1) org.apache.cocoon.util.CocoonServletRequest
>   This wraps up HttpServletRequest.  At first glance, I thought to use
> HttpServletRequestImpl in, but had several additional
> features I wanted.
>   * First, I wanted the name to be recognizable from other applications
> as a Cocoon component.  This makes it clear what is being used and what
> library it belongs to.
>   * Second, I wanted to actually allow servlets using Cocoon to wrap a
> real HttpServletRequest, but still be able to add Cocoon and application
> specific params.  So this wrapper will return the values from the
> HttpServletRequest object passed in if it is present.  This makes it a
> usable construct throughout the rest of an application, not something
> just used for Cocoon and then thrown away.
>   * Third, I want to be able to add params (such as a producer or
> processor) for Cocoon.  So there is a addParameter(String name, String
> value) that allows the addition of parameters to the pseudo-request.
> When a call to getParamterNames() is made, the complete set of both
> original HttpServletRequest (if present) param names and the custom
> added ones is returned, with no distinction to the client.
>   * In the case of params, as in getParameter(String name) or
> getParameterValues(String name), the custom paramters are always
> returned (if they exist) before checking the passed in
> HttpServletRequest (if present).
>   * This allows you to pass in a document (String), a file (File), and a
> request (HttpServletRequest), or any combination of those.  It also
> should work as is instead of HttpServletRequestImpl if desired (it
> handles all the file path and things).
> 2) org.apache.cocoon.util.CocoonServletResponse
>   This wraps up HttpServletResponse.  It is exactly the same code as
> HttpServletResponseImpl but moved into a new file
>   * This was done to facilitate the same naming as it's partner,
> CocoonServletRequest.
>   * This can be used in non-servlet applications, or where a servlet
> does not want to let the output go straight to the screen.
> 3) org.apache.cocoon.example.CocoonFromServlet
>   This is the simple example of how this can all be used.  It uses the
> new singleton method of getting the Cocoon engine, and the wrapper for a
> HttpServletRequest.  It also shows how Cocoon transformed text can be
> used in the middle of other application-outputted text (I have lots of
> ideas here, but it's still bumping around in the brain, so I won't say
> anything yet...).
> In any case, these all work nicely, hopefuly Stefano you can commit
> these soon so I can add Turbine integration examples.  Thanks, guys.
> -Brett
View raw message