cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maciek Kaminski
Subject Re: [C2]Action proposal (long)
Date Fri, 01 Dec 2000 11:08:36 GMT
On 1 Dec 2000, at 1:19, Giacomo Pati wrote:

> 
> --- Maciek@rocketmail.com, UNEXPECTED_DATA_AFTER_ADDRESS@.SYNTAX-ERROR.
Strange, my address is: maciejka@tiger.com.pl
> 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.
> 

I realize that both ways are equaly "expressive". I am not concerned 
about not being able to do something, but about not beeing able to do 
it in a way that does not breaks style and content separation.


Maciek Kaminski
maciejka@tiger.com.pl

Mime
View raw message