cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <pati_giac...@yahoo.com>
Subject Re: [C2]Action proposal (long)
Date Fri, 01 Dec 2000 09:19:47 GMT

--- Maciek@rocketmail.com, UNEXPECTED_DATA_AFTER_ADDRESS@.SYNTAX-ERROR.
wrote:
> Problem with <handle-error>
> 
> > --- Giacomo Pati <giacomo@apache.org> wrote:
> > > --- maciejka@tiger.com.pl wrote:
> > > ...
> > > Other problem with <handle-error> I see:
> > > If administrator can't choose generator for given error than
> > > error handling is up to transformation author, not up to site
> > > administrator? Is it constistent with Cocoon goal to keep
> contexts
> > > (management and style) from overlaping?
> > 
> > Well, there is no need to select another generator for an error
> > situation. An error is an error, point. It's descibed in a DTD and
> thats
> > it. You are able to style the error if you want to present it to
> the
> > client.
> 
> This is my point: Styling errors breaks style and content separation.
> 
> Only developers are interested in stack traces, etc. Other users
> should
> be presented with some explanation: "We are sorry but we have
> temporary 
> problem, etc...". Explanation should be up to content designer, 
> it may include exact error info like stack trace, etc, but not
> necessarily 
> so. That is why I think that it should be possible to select
> generator 
> in error situation.

This is what you can do with any stylesheet applied to the generated
error dtd. The point is that you can have a management transformer
which, for example, sends an email to the administrator/developer
informing him of the specific error occurred. The response to the
client can be what ever you like'em to see.

Giacomo

=====


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

Mime
View raw message