Another approach:
Call NotificationObject = NotificationService.new() to create a new
notification object which can have lots of smart getters and setters to
default things.
Manually set or use a property name list loop to set the appropriate
properties for the Notification object.
Then call NotificationObject.send() or
NotificationService.send(NotificationObject) depending on which way your
preferences swing.
Benefits of this approach are that you can have smarter getters and setters
allowing you to encapsulate a lot of design decisions (you could have an
optional setFromEmail() but the getFromEmail() could be smart enough to say
"if FromEmail set use that, else use system default". Of course, you could
write that logic in the NotificationService, but I think there are benefits
to encapsulating such domain logic in a smart bean.
Two downsides with this approach. One is the cost of object instantation -
if you're sending a couple of notification per request this is fine, but I
wouldn't use it as the basis of a bulk mailer (unless you wrote some object
pooling code in your NotificationService.new() and added some kind of pseudo
destructor to the NotificationObejct to return it to the pool, and even
then, I'm not sure if it'd be worth the grief).
The second downfall is that the API is less obvious. Rather than having a
simple NotificationService.send() with a list of arguments, you actually
have to look at the setters of the NotificationObject bean to understand
what you can and can't (and must and mustn't) set.
Best Wishes,
Peter
On 4/22/07 2:12 PM, "Sean Corfield" <[EMAIL PROTECTED]> wrote:
> On 4/21/07, Marc <[EMAIL PROTECTED]> wrote:
>> The example shows just variables.notificationService.send(.), but I'm having
>> trouble figuring out how the exact call and the actual implementation would
>> look. What goes inside send()? If the message content itself goes in
>> there, doesn't that get messy? Should all the attributes of a CFMAIL tag be
>> accounted for, and if so, how?
>
> There is of course no "one true answer" here but there are lots of
> reasonable degrees...
>
> A simple send() method might take from=, to=, subject=, body= and,
> yes, pass in a string containing the message both. I'm using this
> approach right now for a site I'm working on. Yes, constructing the
> body in the calling code and passing it in is a little messy. See
> below.
>
> It might take an optional arg containing a struct with any additional
> <cfmail> arguments you might want to pass in.
>
> The next step might be a simple templating engine where you pass in
> from=, to=, template= and a struct containing values to be substituted
> into the template. The service loads the template, substitutes all the
> values (they might be identified by something like $${varname} in the
> text of the template) and then sends it. This is how adobe.com's mail
> engine works (both for the main site and for the Hosted Services stuff
> I worked on, albeit different codebases with slightly different
> approaches).
>
> Again, maybe you might pass additional <cfmail> arguments in via a struct.
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at
http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/cfcdev@cfczone.org
