Bob, I like, and use something along the lines of the first method you describe of broadcasting a needFileUpload message with an argument defining the filefield value, although I'm handling the upload directly in the controller rather than in a separate FileUploader component. However I'm not convinced there's a need to go to the lengths you describe to handle file uploads automatically. This just sounds like an actionpack to me. Surely all thats needed is a controller with a method to detect uploads, handle them (possibly using supporting cfc's like an UploadDetector or FileUploader) then set the metadata into the event, which is fired onRequestStart.
Chris 2009/10/20 Bob Silverberg <[email protected]> > Dan and I (and Shannon and Josh) discussed this a bit at CFinNC (more > accurately on the drive to the airport from CFinNC). I realized that one > solution is quite simple: > > 1. Create a utilitiy controller - let's call it UtilController. > 2. The UtilController will listen for a message "needsFileUpload". > 3. That message will accept an argument which will specify the name of the > form field that contains a file. > 4. The controller method invoked via the message will then upload the file > (using a separate FileUploader component), and create a structure containing > metadata about the upload (e.g., success, serverfilename, etc.), and place > that structure into the Event object. It could create an object instead of a > structure, but that might be overkill. > 5. For any event that you know requires a file upload, you add a > needsFileUpload message to the event. > > This would allow for "automatic" file uploads, with all of the code having > to do with file uploads being encapsulated in the UtilController and the > FileUploader. > > This seems like a pretty decent approach, and is something that a developer > could implement themselves without having to worry about MG doing anything > for them. This also follows MG's approach of configuration rather than > convention. You would now have a map in your MG.xml file which shows which > events expect files, so there's some value in that. > > Personally I'd still prefer to be able to have it happen automatically > (i.e., without having to add a message and argument each time I need a file > upload as part of an event), and we discussed that as well. We discussed the > possibility of using conventions (e.g., form field names) and also the > possibility of detecting file uploads automatically and responding to them. > > One idea that was discussed was the possibility of adding a configurable > feature like this to MG. As this does relate to the controller part of the > code, and it's a common requirement, there might be some value in adding > such a feature to MG. The idea is that some sort of FileUploadDetector could > be added to the MG request lifecycle, and folks could choose to implement it > however they felt. When the FileUploadDetector does detect a form field > containing a file, it would then automatically upload it using a separate > FileUploader object, which could be configured via Coldspring, and would > place the metadata for the file upload into the Event object. > > The default FileUploadDetector would not detect any files, and therefore no > files would ever get uploaded automatically. If one wanted to turn on the > feature, one would specify a different FileUploadDetector component that > uses an algorithm for detecting files. Perhaps one component would look for > fieldnames starting with "file_". Perhaps another would look for any field > that contains a file (I have an untested algorithm for that). Perhaps yet > another would respond to messages in the MG.xml file (to allow for > configuration). The point is that if a developer wanted to use conventions > to implement the algorithm they could, and if one wanted to use > configuration they could. And if one didn't want to have anything to do with > this crazy auto-file-uploading scheme, well they'd just accept the default > behaviour. Nobody would be forced to do it a certain way, but anyone would > be able to do it however they pleased. > > I think that this would be fairly easy to implement, and I'd be willing to > take a crack at it, but first I'd like to know what others think of the > idea. Does it sound like a good idea? A bad idea? A crazy idea? Any other > takes on approaches to the same issue? > > Thanks for listening, > Bob > > > -- > Bob Silverberg > www.silverwareconsulting.com > > > > --~--~---------~--~----~------------~-------~--~----~ Model-Glue Sites: Home Page: http://www.model-glue.com Documentation: http://docs.model-glue.com Bug Tracker: http://bugs.model-glue.com Blog: http://www.model-glue.com/blog You received this message because you are subscribed to the Google Groups "model-glue" 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/model-glue?hl=en -~----------~----~----~----~------~----~------~--~---
