CLI broken-link handling (Re: -1 rendered documents, possible bug?)

[Jeff Turner <je...@apache.org>]

Moving to cocoon-dev..

On Wed, Sep 17, 2003 at 01:12:35PM +0100, Upayavira wrote:
> Jeff Turner wrote:
....
> >>I've improved the BeanListener interface to be able to report 
> >>more things as it proceeds, which might help in locating this bug. When 
> >>I've finished with implementation, instead of creating a broken link 
> >>file, it will create a report file, which will detail which pages were 
> >>created, page size, number of links, etc.
> >>   
> >Sounds good.  I think the biggest diagnostic aid for everyday problems
> >would be to know from which page a broken link was encountered.
> > 
> Oh, didn't I mention that? Its in there in my as yet uncommitted code. 

Cool :)

> Just need some more time to get it all hanging together. I'll also want 
> to think broken links through a bit more. Say for example that every 
> page in a 100 page site has a link to a single broken page. That will 
> currently result in 100 broken links, rather than one broken link with 
> 100 parents. I'd like to see if I can get it to report it as one broken 
> link with 100 parents (whilst also reporting broken links as it finds them).

Hmm, not sure.  When you say broken link, don't you mean a link to a
broken page (eg. invalid XML)?  If so, then yes, one page is broken, so
one error should be generated.  If you mean a genuine broken link (link
to nonexistent page), then I'd say that's an error to be reported on its
own.  

But then, in Cocoon I guess its not easy to distinguish between broken
links and links to broken pages.. or is it?

In Forrest, pages are validated before being rendered, so invalid XML
(broken pages) are uncommon.  However, broken links are very common.  It
would be a PITA if the CLI waited until the end of the render to inform
me of broken links.  Typically I halt the build immediately I see one,
fix the link and re-render.


--Jeff

> 
> Regards, Upayavira
> 
> 

Re: CLI broken-link handling (Re: -1 rendered documents, possible bug?)

[Upayavira <uv...@upaya.co.uk>]

Jeff Turner wrote:

> I've improved the BeanListener interface to be able to report
>
>>>> more things as it proceeds, which might help in locating this bug. 
>>>> When I've finished with implementation, instead of creating a 
>>>> broken link file, it will create a report file, which will detail 
>>>> which pages were created, page size, number of links, etc.
>>>>  
>>>>       
>>>
>>> Sounds good.  I think the biggest diagnostic aid for everyday problems
>>> would be to know from which page a broken link was encountered.
>>>
>>>     
>>
>> Oh, didn't I mention that? Its in there in my as yet uncommitted 
>> code.   
>
> Cool
>
>> Just need some more time to get it all hanging together. I'll also 
>> want to think broken links through a bit more. Say for example that 
>> every page in a 100 page site has a link to a single broken page. 
>> That will currently result in 100 broken links, rather than one 
>> broken link with 100 parents. I'd like to see if I can get it to 
>> report it as one broken link with 100 parents (whilst also reporting 
>> broken links as it finds them).
>
>
> Hmm, not sure.  When you say broken link, don't you mean a link to a
> broken page (eg. invalid XML)?  If so, then yes, one page is broken, so
> one error should be generated.  If you mean a genuine broken link (link
> to nonexistent page), then I'd say that's an error to be reported on its
> own. 
> But then, in Cocoon I guess its not easy to distinguish between broken
> links and links to broken pages.. or is it?
>  

Interesting distinction. I'm not really sure if it is possible to 
distinguish. If it is, it'll require much more careful handling of 
exceptions, so as to make the distinction clear. Off the top of my head, 
I think it might require some work within the sitemap, to make the 
<map:handle-errors> report a useful status code for the page.

> In Forrest, pages are validated before being rendered, so invalid XML
> (broken pages) are uncommon.  However, broken links are very common.  It
> would be a PITA if the CLI waited until the end of the render to inform
> me of broken links.  Typically I halt the build immediately I see one,
> fix the link and re-render.
>  
>
Even if I do what I described, I'd still report to stdout as I find an 
error.

Regards, Upayavira