On Jan 30, 2008 12:40 PM, Paul Marcotte <[EMAIL PROTECTED]> wrote:
> Thanks, Peter.
>
> I like your approach. Parameterizing the message type works for me. I
> have some other details to work out, but that gives me a good start.
>
Or you could utilize onMissingMethod if you're using CF8.
I think the notification + email services is too much. When I initially
read this email subject, I thought "there can never be too much." But if
you were just using it to wrap emailService, it would be too much, IMO.
That being said, after you described it, I don't mind it so much. I'd only
use the wrapper if I needed a new name for an existing class to match my
domain terminology.
Sam
>
> Cheers,
>
> Paul
>
>
> On Jan 30, 2008 10:18 AM, Peter Bell <[EMAIL PROTECTED]> wrote:
>
> >
> > All gonna depend on details of your requirements, but some thoughts . .
> > .
> >
> > You might want to mail.send() - not EmailService.send(mail)
> >
> > sendUserWelcome(user), or sendUnsubscribeRegret(user) work, but I'd be
> > more
> > tempted by:
> > Notificationservice.sendMessage("UserWelcome", User) if possible as it'd
> > make it easier to provide a cms to allow site admins to add, edit and
> > delete
> > message types without having to generate methods based on their changes
> > (although that'd work if you wanted to do it that way).
> >
> > Personally I have a notification service, but I don't have an underlying
> > email service or email object. I just let the notification service
> > handle
> > all emails so if my implementation varies I have one place to change it
> > in
> > (and I have a single method within the service that actually sends out
> > the
> > emails so I only have a single cfmail tag in my application). That is
> > enough
> > for my use cases, but as with all of the above, your mileage might vary!
> >
> > Best Wishes,
> > Peter
> >
> > On 1/30/08 1:06 PM, "Paul Marcotte" <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > Hey all,
> > >
> > > I'm putting in a big push to refactor a legacy site (served a la
> > > vongole) to OO. One thing I definitely want to implement is an
> > > EmailService and Email object. I get that it helps to encapsulate
> > > default setting, whether I'm in development mode, etc, but I don't see
> > > any benefit beyond that. What I am considering is add a
> > > NotificationService that composes the EmailService. Why the extra
> > > abstraction? In terms of service methods that send to mail a
> > > customer, it seems strange to replace a <cfmail /> tag with:
> > >
> > > mail = EmailService.createEmail();
> > > // set properties
> > > EmailService.send(mail);
> > >
> > > How I would like to process mail in a service would be to call a
> > > NotificationService with methods like sendUserWelcome(user), or
> > > sendUnsubscribeRegret(user) and have the NotificationService extract
> > > the details from the user object and delegate the actual mail sending
> > > to the EmailService.
> > >
> > > Is this a reasonable extra level of abstraction, or overkill?
> > > Thoughts?
> > >
> > > Paul
> > > >
> >
> >
> >
> > > >
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CFCDev" 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/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---
