cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Willie Wheeler" <wwhee...@andrew.cmu.edu>
Subject RE: Pulling the HTML out of CocoonServlet
Date Sat, 24 Jun 2000 13:34:55 GMT
Hi Giacomo,

	I'm not sure what the best way is to send code, but I guess I will just
attach it.  Here is my first pass at pulling the HTML out of CocoonServlet.
I created a Reporter interface (for reporting not only exceptions, but
simple messages as well).  I also wrote a HtmlReporter class, which formats
exceptions and messages in HTML.  Let me know if this is going in the right
direction.

	Willie










-----Original Message-----
From: Giacomo Pati [mailto:Giacomo.Pati@pwr.ch]
Sent: Saturday, June 24, 2000 1:42 AM
To: cocoon-dev@xml.apache.org
Subject: Re: Pulling the HTML out of CocoonServlet


Hi Willie

On Fri, Jun 23, 2000 at 09:32:56PM -0400, Willie Wheeler wrote:
> Hi Giacomo,
>
> 	Can you explain the idea of contexts here in more detail?  Are the
contexts
> just the different targets to which the XML could be transformed?  (I am
not
> familiar with SOAP, sorry.)

Cocoon will be used in different contexts. Mostly in the HTTP environment
but also as mail creator, or atthe commandline to generate some documents.

> What would the API for the abstract
> context-neutral class look like?  If I understand you correctly,
> CocoonServlet would delegate to an ErrorReporter, which contains the
> hardcoded HTML (or whatever other formats we output to).

The idea is not very concrete. I first thought of an simple CocoonException
every Exception that should arrive the calling environment is based upon
(something that we as developer must make sure). Based on the environment,
cocoons can be configured to use a subclass there of for rendering the error
message (as an web page, as a mail, ...)

> Is it important
> for end users to be able to modify/customize the error messages that
Cocoon
> displays?  If so it might be better to use a server page and XSLT, as
> opposed to a Java class.

Not, realy. It is good to use an interface/abstract class in the core cocoon
and have a subclass be defined for a specific environment. If someone
doesn't like it, he can change almost the java class.

> 	Let me know what you think.  And if you already have some concrete plans
on
> how to proceed, tell me what they are so I can get started!  :-)

No concrete plans, just thoughts.

Giacomo

--
PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen                    Web:   http://www.pwr.ch


Mime
View raw message