cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject [RT] Fixing the CLI
Date Mon, 24 Feb 2003 13:24:27 GMT
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.).

Also, it is important to output the links AS IS.  The fact that
Cocoon CLI and Cocoon live produce different results is plain
wrong.  If I want my HTML file to have a .foo extension, then
I should be able to do that without any problems.  Currently the
CLI version converts it to a .foo.html.  I don't think that it
should--or at the very least, it should be an option to turn off
that behavior.

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.

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.  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?

View raw message