Hey Elliot, Those are some excellent and very valid points. I understand your concerns behind the cfhttp approach, that's certainly very valid and is something which has been niggling in my mind and certainly something I'd like to avoid where possible.
Your approach with custom tags is certainly very nice, so for instance you'd have a custom tag called 'draw_invoice_table' which would accept an invoice object and then format it into the appropriate HTML? hmmm that's a very nice approach, I'll be honest, I've never really worked with custom tags at all, I never give them a second thought, I'm certainly guilty as charged on that one. The difficulty I have with just including it as a view below is that much of my email work isn't just single emails, it's groups of emails distributed as part of scheduled tasks, they're not done by a user action, so just get this right, inside your emails/ contactus_notification.cfm would you actually have the cfmail tag? Cheers guys, Rob On 5 Aug, 02:44, Elliott Sprehn <[email protected]> wrote: > On Aug 3, 11:35 am, Sir Rawlins <[email protected]> > wrote: > > > > > For instance, within the application I have a view which is called > > 'dspInvoiceDetails.cfm' this contains the basic raw table layout for > > an invoice object to present to the user. I currently use this in a > > standard web view, however, I'm now looking to take this table place > > it into an email, and also inside a PDF attached to that email. It > > seems a shame to have to duplicate that table output code in three > > separate locations doesn't it? > > This is a job for... wait for it... Custom Tags! Huzzah. :) > > We encapsulate such things into widgets in the form of Custom Tags > that are invoked inside the various views. > > I think people get very caught up trying to shoehorn everything into > MG/{insert framework here} and forget that CF already solved their > problem. > > > The premise I've been working on at the moment here is to have events > > defined for the different emails which contain broadcasts for the > > required data, a result for the email template and then includes the > > views I require (just like a normal event really). I'm then looking to > > generate a model component which makes an HTTP request to these > > events, I can then use that cfhttp.filecontent variable to produce > > emails, pdfs or other such things, does that approach sound any good? > > I wouldn't do this. It generates double the load on your server than > would normally be required and you're going to run out of requests > threads twice as fast, especially if these requests take a while. > > The way we handle email is to have an event that renders the email, or > sometimes just <include> it with the other views. > > <event-handler name="contactus_complete"> > <views> > <include name="email" > template="emails/contactus_notification.cfm"/> > <include name="body" template="pages/contactus_thankyou.cfm"/> > </views> > </event-handler> > > Both those views might use shared display logic, but that will be > encapsulated inside custom tags. > > The simplest solution is often the best one. cfhttp is your sledge > hammer. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
