With HTTP, we have a lovely Response object that not only provides a way of serializing the page to the end user, but also allows us to set the HTTP return code for the page and its mime-type, etc.
It is clear that we are not using this to our advantage with the Command Line Interface to Cocoon. The fact that we can't easily turn off error page generation for static web sites (that will integrate with stuff generated or preexisting by other tools), proves that we are not leveraging the HTTP return code to our advantage. Any Response with a return code in the 200s is good, and any response with a return code that is 300+ is bad.
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.
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.
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)
Currently the
CLI version converts it to a .foo.html.
The CLI obtains the MIME-type first, changes the URI, then requests the page with the link translated accordingly.
> I don't think that it
should--or at the very least, it should be an option to turn off that behavior.
I agree that this (much slower) behavior could be turned off by a command line setting, if not needed, but saying that this is 'plain wrong' is definately an overstatement.
The CLI should be able to determine--in one pass--what the error condition of a page is, the mime-type, and the actual page itself. That would obviate the need for much of the multi-pass architecture now.
Grrr, I hate when people talk without even looking at the code! The multi-pass architectur is not done like this because it's fancy, but because there is no way (or at least, nobody could find it until now), to obtain information on MIME-type + having the ability to perform link translation before the serialization stage!
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.
currently, we have a way to call the view directly which is even better. what different would it make?
That way the CLI version can do all it needs to do in one pass. THat seriously beats the multipass approach it has today.
What do you all think?
I really don't see how you can do link translation in one pass.
-- Stefano Mazzocchi <[EMAIL PROTECTED]> Pluralitas non est ponenda sine necessitate [William of Ockham] --------------------------------------------------------------------
