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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------