[Zope-CMF] Re: Information and Questions on CMFExternalFile

[Carl Rendell]

I've been working on this project most of the day today, and thought 
I'd share a few things with the list.

First, I've been able to get both products working in the CMF 
environment more or less the way ExtFile and ExtImage work in native 
zope (zmi). That includes the preview (thumbnail) functionality for the 
image product. Nothing is final yet, but the products are working. To 
accomplish the change I did the following:

ExtImage -

o Changed skins to zpt to allow compliance with page templates
o Changed edit file to Python Script to follow standardard CMF (after 
1.3) protocol
o Modified edit method in CMFExtImage to allow creation of Preview 
Images
o Modified edit form to allow creation of Preview Images
o Modified view template to provide preview image
o Modified edit method in CMFExtImage to reindex item in catalog during 
edit

ExtFile

o Changed skins to zpt to allow compliance with page templates
o Changed edit file to Python Script to follow standardard CMF (after 
1.3) protocol
o Modified edit method in CMFExtImage to reindex item in catalog during 
edit

Now I've got products that function like others in the CMF family 
including using page templates and python scripts. However, As I go 
through this exercise I find some things in the products that bother me.

Three levels of Hierarchy (e.g. CMFOptions.CMFExtImage.ExtImage)

This seems like a waste to me because there is little else accomplished 
other than a convenient distribution of products. There seems to be no 
value in sub-classing ExtImage or ExtFile for the CMFWrappers as these 
are not used anywhere else in the product suit.

I'd prefer either single products distributed much like CMF itself to 
avoid at least one level of hierarchy. Perhaps even combining 
CMFExtImage with ExtImage to have one product since there is little if 
any development on either on today.

Dot Undo Files (.undo)

Understand the rational here, but it would nice to connect the removal 
of these files to the act of packing the database. It's not very 
elegant to have users going in and messing with the file system 
especially since the undo files are in the same directories as the 
current versions.

At a minimum I'd want two trees - current and undo - to make the task 
of clean up more straight forward. Better yet. Provide a tool which 
allows users to clean up the .undo files from the zmi. Ideally this is 
coordinated with packing the database as the two events typically 
coincide with one another.

Coordination of Thumbnail Creation

Ok this is a nit, but the creation of preview images is another odd 
one. To create a 'nice' version you need to upload a new source file 
each time you make a change. I'd prefer it if the the workflow inside 
the product went more like:

   New Image
   o Upload Main Image
   o Create/Modify Thumbnail

   Change Image
   o Create/Modify Thumbnail if parameters change or new file is 
uploaded.

That's about all I have time for. If anyone is interested in the 
progress of these products let me know, and I'll keep them in the loop.

If anyone would like to add their two cents, they are welcome. In some 
way's I feel as though these External File and Image products should be 
part of the standard CMF distribution much like SkinnedFolder is now. 
Allow the person doing the CMF install to decide if they want binaries 
in the ZODB or in the file system. Ah well, perhaps CMF Corporation 
will add this to their CMF 2.0beta distribution.

~C

On Saturday, April 5, 2003, at 10:53  AM, Carl Rendell wrote:

> Finally got around to playing with CMFOptions - specifically 
> CMFExtFile and CMFExtImage.
>
> For the most part everything went together fine once I had the patch 
> from Tres.. Thanks Tres!
>
> However, I'm having a couple of issues with CMFExtImage that I've been 
> unable to isolate:
>
> 1. Image Size for jpeg - The CMF implementation uses the same code as 
> OFS.Image to provide image width and height for the image tag, but 
> with and hight for jpeg images are not rendered - all other types 
> (gif, and png) render fine.
>
> Looking at the modified ExtImage product I found that the PIL call in 
> the private method '_getImageSize' had been commented out. Changing it 
> back to what was in the standard (non CMFOption) version of ExtImage 
> fixed this issue. It does make the product dependent upon PIL though.
>
> 2. Image Preview - I'm still working on this one, but for the moment 
> I'm unable to get Preview Images generated even after modifying the 
> dtml to pass the preview information. Note: the preview info has been 
> omitted from the CMF version of the ExtFile dtml forms.
>
>
> Questions -
>
> For number one - is anyone having similar issues with jpeg width and 
> height attributes when creating image tags via the .tag method? If so, 
> was a different method employed to accomplish this (as opposed to 
> using PIL)?
>
> For number two - is anyone using the preview functionality of 
> ExtImage, and if so how was this accomplished?
>
> I'm in the process of changing the product(s) to be closer to the 
> current CMF product types with page templates for forms, and python 
> scripts for the edit/change functionality. I'm more than willing to 
> package the whole thing up and put it out on zope.org once I've 
> resolved the issues with jpeg size and preview images.
>
> Thanks,
>
> ~C
>
> Carl E. Rendell
> Solution43
> Information Distribution and Process Consulting
> cer@sol43.com
> sol43.com
>
>

Carl E. Rendell
Solution43
Information Distribution and Process Consulting
cer@sol43.com
sol43.com