I have a modified upload behavior I can share, although I don't have the latest version up - but I can have it up a few hours.
The upload behavoir can upload any filetype (currently I use it for images and MP3's) to any subdir under the webroot. Its current features also include correcting filenames (replacing spaces, + and & characters) and can produce a thumbnail (using a additional controller for PHPThumb) for jpeg and png images, with the name 'thumb.filename.ext'. The image is then easily accessible from the database with dir and filename fields that you can use in any image tag or link. The only issue is that it will delete the image, but not the thumbnail. Its a small isue that's not bothered me until now so I havenj't fixed it. Once I post the latest version, I've give an example of how to use it here. On 6/7/07, Allen Romero <[EMAIL PROTECTED]> wrote: > > Is there a good example of how to upload an image to the server and > serve it up, etc? > > thx in advance, > > allen > > On Jun 6, 2:38 pm, AD7six <[EMAIL PROTECTED]> wrote: > > peterhf wrote: > > > I have been influenced by the argument given a sites such as > > >http://cakebaker.42dh.com/2006/04/15/file-upload-with-cakephp/. There > > > is a logic to me, that having the image and the data surrounding the > > > image are in one place, not devided between two places which would > > > require attention to not allowing the two from becoming out of sync. > > > > > I am certainly open to opposing views as I am new to dealing with > > > large quantities of images. > > > > I'll chuck an opinion in :). > > > > Sticking large numbers of image files in a db is handy in that the > > data is all in one place, but awful from several other perspectives. > > Storing the file path/meta data in the db so you know where things are > > and you can treat them as an object (i.e. link a user to an image or > > whatever) makes sense; to me putting the image data in the db is just > > an overcomplex means of achieving an inefficient solution. Unless you > > have a very good reason to do so, and it would have to be a reason > > that serving image files (which are outside of the webroot) with php > > doesn't solve, it would be best avoided. > > > > disadvantages I can think of: > > > > 1) Php serving an image is slower than just letting apache doing it, > > and significantly more so if you have to get the image source from the > > db. > > 2) You add dependencies to the db (and php if appropriate) you > > otherwise don't have to serve images > > 3) php's image functions work only on files afaik > > 4) It's going to take up more space in a db than it would on the file > > system > > 5) A db field has a size limit per file, a file system doesn't > > > > I'm sure there are more. If anyone has one of those "very good > > reason"s I'm game to be enlightened ;). > > > > hth, > > > > AD > > > > > -- Tane Piper http://webrocket.wordpress.com This email is: [ ] blogable [ x ] ask first [ ] private --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
