I agree that file uploading should be made as generic as possible, and
enabling some callbacks for file processing should be a great bonus.
I used uploadBehaviour as published in the Bakery for a recent project
and -though it really simplified my work- I had to make some
adjustments for it to work properly. Still I wasn't happy with it
being so image oriented and also I would prefer not to hardcode the
file fields in the DB model (id, name, photo1, photo2, photo3, pdf...)
which, for example, limits the number of images a post might have.
IMHO, this should be addressed in a similar fashion to
translateBehaviour, where an extra table is added to the DB and
associations are made on the fly to the corresponding model. That way
we could have Post hasMany Files, defining file type as 'image',
'video', 'pdf', or whatever and allowing setting up a callback to
handle any extra file manipulations.
The architecture for such a solution doesn't seem trivial, but it
certainly can and should be done as it would be of great value for the
framework itself and for all the bakers out there.
I'm really short on time these days, but will give it a try. Anyone
else? :)
On 13 jul, 09:12, AD7six <[EMAIL PROTECTED]> wrote:
> On Jul 12, 1:53 pm, Tijs Teulings <[EMAIL PROTECTED]> wrote:
>
> Hi Tarique,
>
> The behavior in cheesecake is almost stripped to the bone, and has
> some assumptions built in (where the files will go meaning the use of
> WWW_ROOT, each file is a foto, the format for the name of the thumb
> file etc.). For a photo driven site I guess it's what's needed.
>
> Hi Tijs,
>
> The paste was not for a finished version but I did a bit more than
> change the way the default setup works. I added/did the following:
> * style changed to be more inline with other behaviors (use of
> extract so you don't need $this->params to refer to all your variables
> for example)
> * changed to work with almost no parameters
> * made separate methods for some operations such as determining file,
> thumb and path names
> * the folder to save can be configured/changed on the fly 'dir' =>
> '{APP}uploads{DS}{$class}{DS}{$foreign_id}' <- those get replaced when
> used
> * the thumb/versions to save can be configured/changed on the fly
> ''name' => '{$file}.small.{$ext}' <- can be what you like
> * added a name cleanup routine (only applicable if you are not using
> random filenames) so that áccëñtèd characters in file names are
> converted
> * fixed the beforeDelete method and wrote it to ensure that the pics/
> thumbs/versions of abcd.jpg are not deleted when you delete the pic
> bcd.jpg
>
> I changed it to use relative file paths when saving to the database,
> although that's currently hard coded. Not sure if it is still a bit
> too db-centric as a model may not be a table in the db of course.
>
> The thing that mildly bugged me before was that a file (upload) is a
> file, not a jpeg/png. The behavior was and still is (because I decided
> to stop thinking and just write something) a bit foto centric imo. I
> need to be able to upload images and pdfs, but the same upload
> behaviour could be used for any file type, so if it includes image
> resizing, shouldn't it include any of doc to text, text to pdf, mp3 to
> first x seconds, movie to first x seconds, unzip zip etc. ?
>
> I like the way cheesecake keeps things separate by outsourcing image
> manipulation to a vendor. Maybe configuring a callback is a
> possibility, maybe image resizing should be done in the model or maybe
> I'm thinking too much.
>
> Anyway, thoughts?
>
> AD
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---
