[Zope-CMF] Re: Information and Questions on CMFExternalFile
Carl Rendell
cer@sol43.com
Sat, 5 Apr 2003 17:23:07 -0800
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