Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
To: cocoon-dev@xml.apache.org
From: Jeff Turner <jefft@apache.org>
Subject: Re: Cocoon CLI broken
Date: Tue, 27 May 2003 09:04:29 +1000
Lines: 97
Message-ID: <bau6lo$1hu$1@main.gmane.org>
References: <20030525103151.GA32257@expresso.localdomain>
 <3ED1B7EE.5456.1D4E77@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4a) Gecko/20030401
In-Reply-To: <3ED1B7EE.5456.1D4E77@localhost>
Sender: news <news@main.gmane.org>

Upayavira wrote:

> Jeff,
> 
> I'll happily look into this.

Thanks! But see below -- problem is mostly user stupidity, and I think I 
can fix the remaining bug myself.  I'll ask if I get stuck.

> I presume I can download the site from the cocoon-site module?

It would involve:
  - Checking out xml-forrest
  - Running build.{sh,bat}
  - Running build/dist/shbat/bin/forrest
  - Checking for badly named files in build/site/

>>I've just noticed: the command-line rendering in Cocoon M2 leaves
>>build/site/ full of bogus files for site: and ext: links:
> 
> 
>>[xml-forrest ~/build/site]$ ls site*
>>site_bugs
>>site_changes
>>site_contrib
>>site_document-v12
>>site_faq
>>...

I'm embarrassed but happy to say, I no longer see this behaviour. I'm 
not sure where it came from; perhaps an earlier experiment with the 
one-pass CLI.  Sorry for the noise ;)

> I presume you're using the multiple-generation/link-view/check-extensions version?

Yes.

>>Also, it doesn't like non-standard extensions for files:
> 
> 
>>[xml-forrest ~/build/site]$ ls -1 images/*.jpeg
>>images/add.jpg.jpeg
>>images/fix.jpg.jpeg
>>images/hack.jpg.jpeg
>>images/remove.jpg.jpeg
>>images/update.jpg.jpeg

This we resolved simply by using the correct MIME type (image/jpeg, not 
image/jpg).  *.js was fixed in the same way (using 
application/x-javascript instead of text/javascript).

> That looks like the traditional 'check-extensions' behaviour. Given that it appends the 
> default extension for the mime-type, in this case, image/jpeg, jpeg is appended to a 
> jpg file. I haven't changed this code at all, so I can only imagine that this has always 
> been its behaviour (or someone changed MimeUtils). Anyway, it doesn't look very 
> hard to fix with a couple of tweaks to MimeUtils (e.g adding a 
> confirmExtension(mimeType, extension) function.
> 
> 
>>And for unknown files, it appends 'null' to the filename:
>>
>>[xml-forrest ~/build/site]$ find . -name "*null"
>>./skin/breadcrumbs.jsnull
>>./favicon.iconull

favicon.iconull is still a problem.  MIMEUtils doesn't contain an entry 
for 'image/x-icon'.

Also, any files copied with an unknown MIME type end up with a 'null' 
suffix.

So the only change that's really needed is a null check on what 
MIMEUtils returns.  If no MIME type is found, the original filename 
should be used.  I'll try this tonight.

Secondarily, it would be nice for MIMEUtils to read the MIME type list 
from a .properties file.  Then users could edit the mapping themselves. 
  For instance, users might want to have text/html files saved with a 
.php extension.

...
>>Fortunately, for every wrong file, it also generated the correct file
>>alongside it, so this isn't a critical problem, just an annoyance.  
> 
> 
> Huh? Bizzarre. Again, I'll look into it.

I should have realized my mistake when writing that ;)

thanks,

--Jeff


> Regards, Upayavira
>