> Well here I have this Subscriber object, let's call it. They
> signed up
> on a web form, and I've poulated the object with the validated data.
>
> what would I like to do with the Subscriber?
>
> o send them a welcome mailing
> o snailmail - add them to tommorow's list of mailing
> labels along
> with a marker to the correct template
> o e-mail - send them a greeting using the welcome template
> o add them to a database
> o retrieve them from a database
> o based on certain criterion, send them monthly mailings
> of special
> events
> o based on certain criterion, send them coupons on birthday or
> anniversary
>
>
> The Subscriber object, can, as necessary, generate from itself a
> complete address, complete email, greeting (including salutation, for
> use in templates), make sure we've entered a valid date for
> b-day/anniversary, etc.
>
> There's other things but by and large I can program them into the admin
> interface easily enough, but my thought is to abstract away some of the
> functions in order to simplify the interface programming.
>
> # clone the subscriber and send them a welcome greeting
> my $mailer = Subscriber::Mailer->new($subscriber);
> # fill in the welcome template
> $mailer->add_template( $template_object );
> # fire it off
> $mailer->send() or generate_some_sensible_error($!);
>
> There's still the part that needs to determine whether we're sending
> them an e-mail or a printed mail to a snailmail address, to consider,
> but this is the 'raw idea' of the thing.
Ok, so you want to create wrapper classes to provide a generic interface into a bunch of arbitrary classes, thats not quite what i thought you had in mind. Presumbly there still will be some object in your framework with a HASA relationship to those wrappers?
Yves
