Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E5A25E8.2050006@apache.org>
Date: Mon, 24 Feb 2003 09:02:16 -0500
From: Berin Loritsch <bloritsch@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Fixing the CLI
References: <3E5A1D0B.5000101@apache.org> <3E5A22DD.4000505@apache.org>
In-Reply-To: <3E5A22DD.4000505@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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.

> 
>> 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)

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.

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

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

One pass, and I get all the information I need.  Which in this case
is better.