cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Fixing the CLI
Date Mon, 24 Feb 2003 13:49:17 GMT
Berin Loritsch wrote:
> 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                               <>
    Pluralitas non est ponenda sine necessitate [William of Ockham]

View raw message