Re: [C2]Action proposal (long)

[Giacomo Pati <pa...@yahoo.com>]

--- Maciek@rocketmail.com, UNEXPECTED_DATA_AFTER_ADDRESS@.SYNTAX-ERROR.
wrote:
> Problem with <handle-error>
> 
> > --- Giacomo Pati <gi...@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/

Re: [C2]Action proposal (long)

[Maciek]

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 <gi...@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