cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [RT] Fixing the CLI
Date Mon, 24 Feb 2003 15:25:51 GMT

Berin Loritsch wrote, On 24/02/2003 15.02:
> Stefano Mazzocchi wrote:
>> Berin Loritsch wrote:
>>> If we leverage that information, we can suppress the output of
>>> pages that are redirects or simply error conditions (resource
>>> not found, permission denied, 500 style error, etc.).
>> Sorry, I don't understand what you are implying here.
> Implying?  I am stating that if a page is not successfully
> generated, I do not want a generated error page.  I.e.  Success or
> nothing.  If the CLI has a 400+, 500+ style error code, then it
> should be able to suppress the output of that page.
> THat way tools that are designed to find broken links will actually
> find broken links.  ALso Cocoon (and hense Forrest) won't overwrite
> existing files or files generated by other tools.  Many projects
> do have heterogenious environments--it is a fact of life.

Yes, Berin, I know and understand.
I've been looking to fix it in the past days but it's not so easy, look 
at the code. The fact is that Cocoon itself generates it via 
handle-errors and using the Environment _writes it down_.

Cocoon dies not give you back a file! So it's a black box that makes 
that file and returns a response. But the file is already committed.
I tried renaming the file but it doesn't work.

Still digging...

>>> Also, it is important to output the links AS IS.  The fact that
>>> Cocoon CLI and Cocoon live produce different results is plain
>>> wrong.
>> uh? yes, it's a workaround against the stupid concept that most file 
>> systems do not have an orthogonal way to indicate the mime-type of a 
>> file. Only good old macos file system has such capabilities.

It should be switchable via a parameter. Also on my TODO.

>>> If I want my HTML file to have a .foo extension, then
>>> I should be able to do that without any problems.
>> Then you burn your generated web site on a CDROM, ship that and nobody 
>> will ever be able to open that file (note, also, that IE has a bug on 
>> handling MIME-types for URL that don't terminate with the extension 
>> that windows expects)
> Not necessarily.  HEre is a case that happens:
> The link is foo.pdf.  THe PDF file is either a pre-existing file
> generated from another source, or there was an error generating it
> from Cocoon.  Cocoon mangles the link to foo.pdf.html and outputs
> an error page.  Bad.
> Same thing with graphics files.
> As to you last argument--trust the user to have some intelligences.
> You can output a warning if you want, but if I don't want my URLs
> mangled, I should expect to know what I am doing.  We aren't all
> neanderthals or need spoon-feeding.

We can be or not. I'll just make a switch for it.

> The above errors and problems are what I am really wanting to address.

They are being addressed. Thanks you for reminding.

>>> Lastly, things like different views should be accessible via
>>> parameters.  The CLI sends in the Request Parameters, so it
>>> should be able to acess the results from the different views
>>> via the Request Parameters. 

I don't get it. Could you please explain to me again?

>> currently, we have a way to call the view directly which is even 
>> better. what different would it make?
> One pass, and I get all the information I need.  Which in this case
> is better.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message