cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: Beautify 404
Date Tue, 24 Jul 2001 13:39:27 GMT
> Vadim Gritsenko wrote:
> 
> Carsten,
> 
> > 
> > > Vadim Gritsenko wrote:
> > >
> > > Hello everybody,
> > >
> > > Checked in changes to allow custom 404 page. To use it, just add
> > > something like this
> > > to your <map:pipeline>:
> > >
> > >    <map:handle-errors type="404">
> > >     <map:transform src="stylesheets/system/error2html.xsl"/>
> > >     <map:serialize status-code="404"/>
> > >    </map:handle-errors>
> > >
> > > Other possible value for type attribute is 500 - which is
> > > default; the meaning for 500 type
> > > erorr handler is the same as before, and type attribute is
> > > optional (preserving old syntax).
> > >
> > Could you explain this a little bit more. I assume that the
> > 404 is equivalent to the ResourceNotFoundException, right?
> 
> Yes, that's right.
> 
> 
> > So if this exception is thrown somewhere (e.g. in a generator)
> > the above error handler is called.
> 
> If handler is present in this pipline, or in parent's pipeline 
> (where map:mount element is).
> If not, exception will be handled by CocoonServlet.
> 
> 
> > But what does error type 500 mean? Every exception?
> 
> Before we had the only <map:handle-errors> element for pipeline for all
> exceptions EXCEPT ResourceNotFound and ConnectionReset - this is 
> preserved,
> which means that yes, 500 means all errors except mentioned two.
> 
Ok, I am not so happy with the 500 here as it is not so intuitive
what is really meant with it.
> 
> > Can I have two (or even more) map:handle-errors in one pipeline?
> 
> You can have up to two <map:handle-errors> elements - one of every type.
> Right now this is not enforced, but I can implement this.
> 
I think we should keep compatibility were possible and  the 500
is not so verbose.

> 
> > 
> > > It is allowed to use own generator:
> > >
> > >    <map:handle-errors type="404">
> > >     <map:generate type="serverpages" src="my404.xsp"/>
> > >     <map:transform src="stylesheets/page2html.xsl"/>
> > >     <map:serialize status-code="404"/>
> > >    </map:handle-errors>
> > >
> > > Every <map:pipeline> might have own customized 404 page; if no
> > > page is specified,
> > > CocoonServlet will process an error. If request did not match any
> > > pipeline, 404 page from
> > > last pipeline will be used.
> > Did I get this right? If I have two map:pipeline sections and no
> > match is found and the second pipeline has no customized 404 page
> > then the one of the first map:pipeline is used?
> 
> No. If there is no customized page for the last pipeline, 
> ResourceNotFound will
> be handled by Cocoon - i.e, empty SC_NOT_FOUND response will be sent.
> 
Ah, good.

> That's because it is not possible to determine to what pipeline 
> user's request
> was originated, so right now if no pipeline matched, 
> <map:handle-errors> element
> used from the LAST pipeline in the sitemap.
> 
> Actually, this is the part where people's opinion should be taken 
> in account.
> Another way is to explicitly set <map:handle-errors> element for 
> <map:pipelines>
> element (note "s"!) - but I do not like this for some reason...
> 
Agreed.
> 
> > 
> > Hm, I'm sorry, but I think changes like this should a) first
> > discussed before checking in and b) first checked in into the
> > 2.1 branch.
> 
> I do agree with you here... My decision was based on fact that I 
> proposed this change
> back in June 30 and there were no objections since then. 
> 
Oh, I must have overlooked it. 
> 
> > There were months ago many discussions about this features
> > among with a customizable ErrorGenerator. That was very close
> > to this solution, but the team agreed to drop it.
> 
> Actually, I did not touch generators or notifiers - just some 
> simple extensions to
> sitemap syntax.
> 
> > 
> > I don't want to say that your solution is bad or wrong, but
> > I would like to have only few changes to c2 to get a final
> > release.
> > 
> 
> If you feel uncomfortable about this change - may be we should vote
> to decide where to keep this. I do share your concern about 
> Cocoon stability,
> but this is comparable unsignificant change which many users are 
> awaiting for.
> 
> So, 2.0 or 2.1?
I think as it is in the 2.0 branch now, it works and there are needs
for it, we could leave it there. 

But what I don't like is the new generator node in the handle-error,
so I vote for leaving it in 2.0 but removing the extra generator
handling in both cvs.

Carsten
> 
> Vadim
> 
> > 
> > Carsten
> > 
> > Open Source Group                        sunShine - b:Integrated
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de                          mailto: cziegeler@sundn.de
> > ================================================================
> > 
> > >
> > > Comments are very welcome.
> > >
> > > Thanks,
> > > Vadim
> > >
> > > > -----Original Message-----
> > > > From: Vadim Gritsenko [mailto:vgritsenko@yahoo.com]
> > > > Sent: Saturday, June 30, 2001 5:01 PM
> > > > To: cocoon-dev@xml.apache.org
> > > > Subject: Beautify 404, Was: [C2][Patch] 
> /map:pipelines/map:handle-errors
> > > >
> > > >
> > > > Giacomo,
> > > >
> > > > "Catch all" would not be enough; if you have something like
> > > <map:match="*.xml">,
> > > > you still can get ResourceNotFoundException which would be 
> processed by
> > > > CocoonServlet, returning hard-coded HTML....
> > > >
> > > > Do you see any elegant solution to this poroblem?
> > > > I suggested to introduce types for <map:handle-errors> element:
> > > >   <map:handle-errors type="404"> <!-- 404 or something else...
> > > like exception class name -->
> > > >   </...>
> > > > What is your opinion?
> > > >
> > > > Vadim
> > > >
> > > > > -----Original Message-----
> > > > > From: giacomo [mailto:giacomo@apache.org]
> > > > > Sent: Friday, June 29, 2001 18:21
> > > > > To: cod
> > > > > Subject: Re: [C2][Patch] /map:pipelines/map:handle-errors
> > > > >
> > > > >
> > > > > On Fri, 29 Jun 2001, Steffen Stundzig wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I've the problem, that I must beautify the page that 
> raises on an
> > > > > > ResourceNotFoundException if no matching pipeline could 
> be found.
> > > > > >
> > > > > > Unfortunately this page is directly written as HTML
> > > > > > into the ServletOutputStream from inside the Cocoon 
> Servlet. Or I've
> > > > > > overlooked something?
> > > > > >
> > > > > > My idea was to use the map:handle-errors element for this
> > > purpose. So I've
> > > > > > changed the sitemap.xsl to support also such an element 
> as child of
> > > > > > map:pipelines and not only as child of 
> map:pipelines/map:pipeline.
> > > > >
> > > > > You can use a "catch all" matcher as the very last one in
> > > your sitemap.
> > > > >
> > > > >   <map:match pattern="**">
> > > > >     ...
> > > > >   </map:match>
> > > > >
> > > > > Giacomo
> > > > >
> > > > > >
> > > > > > If this element doesn't exist, the mechanism is as for now
> > > but if it exist,
> > > > > > the error-page is 'pipelined' in the standard
> > > map:handle-error manner.
> > > > > >
> > > > > > Attached is my patch for this stuff.
> > > > > >
> > > > > > Possibly is anybody interested in it.
> > > > > >
> > > > > > Regards
> > > > > > 	Steffen...
> > > > > >
> > > > > >
> > > > >
> > >
> > >
> > >
> > > _________________________________________________________
> > >
> > > Do You Yahoo!?
> > >
> > > Get your free @yahoo.com address at http://mail.yahoo.com
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message