Re: Subclassing a mailer
Sam Holden wrote: Scott R. Godin writes: I guess I'm curious whether it even makes any sense to continue in an OO vein for this .. I had visions of being able to just package Subscriber::Database; our ($db, $user, $pass) = (dbi:Path:here, username, password); package main; my $db = Subscriber::Database-new($subscriber_object); $db-save() or die Cannot save userdata : $!; undef $db; but perhaps I'm pipe-dreaming? I mean, with an interface like this, I could have $db-retrieve_match( column = thing to match) and step thru the matches or $db-retrieve_all() to get everybody my $href = $db-retrieve_emailers(); # loop thru the results # make a new Subscriber::Mailer object # fire off our monthly mailings from an HTML::Template or Text::Template That's a perfectly good interface, however the Subscriber::Database class would not inherit from DBI, it would simply use the DBI module in order to interface with a database. Inheriting leads to problems such as the next version of DBI introducing methods named retrieve_match and retrieve_all. it's starting to get a little clearer now, yes.. Making the Subscriber::Database class containing generic routines and then inheriting from it to create a Subscriber::Database::DBI class might make sense (that class would just use DBI, not inherit from it). The UML architects would love it. Others would argue that how do you know what it generic until you've implemented two or three of the subclasses - so refactor later... I have further visions of using both DBD::mysql and DBD::AnyData in different instances (exporting the db to a .csv file, for example) ... Encapsulating the database code in a module (or class) is a very good idea. Sprinkling SQL randomly throughout the code is a nightmare I hope you never have to maintain... these seem to be conflicting statements unless you're referring to my desire to pack all the actual SQL into the module so it's NOT in the front-end code and would be 'transparent' to it. -- Scott R. Godin Laughing Dragon Services www.webdragon.net
Re: Subclassing a mailer
On Sun, 16 Jan 2005, A. Pagaltzis wrote: * Sam Holden [EMAIL PROTECTED] [2005-01-15 17:09]: Only inherit when you have an ISA relationship. I just want to chime in to agree. Inheritance is greatly overrated and widely abused. It is almost always the very last option you should consider. Aggregation is way underrated and should be used much more often. Do you have any evidence of this? I can guess that this may be the result of bulk of OOP education emphasizing inheritence so people presume that its the best way when its merely one choice. Given the complexities of inheritence it does require more educational space than aggregation. But I haven't seen the wide abuse you speak of. In my sphere of influence I have to hammer home the importance of semantics in OOP design and I've had to dissuade a few eager souls from inheriting where there's isn't an ISA, but in reviewing other folk's OOP code I would say that a total lack of design sense or standards is much more rampant than inheriting where it doesn't make sense. Since this is a list closely related to CPAN I'm particularly curious if there are examples where published modules are breaking this rule. -- /chris There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author)
Re: Subclassing a mailer
Scott R. Godin writes: I guess I'm curious whether it even makes any sense to continue in an OO vein for this .. I had visions of being able to just package Subscriber::Database; our ($db, $user, $pass) = (dbi:Path:here, username, password); package main; my $db = Subscriber::Database-new($subscriber_object); $db-save() or die Cannot save userdata : $!; undef $db; but perhaps I'm pipe-dreaming? I mean, with an interface like this, I could have $db-retrieve_match( column = thing to match) and step thru the matches or $db-retrieve_all() to get everybody my $href = $db-retrieve_emailers(); # loop thru the results # make a new Subscriber::Mailer object # fire off our monthly mailings from an HTML::Template or Text::Template That's a perfectly good interface, however the Subscriber::Database class would not inherit from DBI, it would simply use the DBI module in order to interface with a database. Inheriting leads to problems such as the next version of DBI introducing methods named retrieve_match and retrieve_all. Making the Subscriber::Database class containing generic routines and then inheriting from it to create a Subscriber::Database::DBI class might make sense (that class would just use DBI, not inherit from it). The UML architects would love it. Others would argue that how do you know what it generic until you've implemented two or three of the subclasses - so refactor later... Encapsulating the database code in a module (or class) is a very good idea. Sprinkling SQL randomly throughout the code is a nightmare I hope you never have to maintain... -- Sam Holden
RE: Subclassing a mailer
Title: RE: Subclassing a mailer 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
Re: Subclassing a mailer
Scott R. Godin writes: [snip disucssion of iheriting from a mailing class] 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 But that doesn't mean you inherit from an address label printing class, an emailing class, a database class, a special events class and a birthday and anniversary class. You simply use such classes to perform each task. Now, some classes have APIs such that you have to subclass in order to use them (many XML parser classes for example) but emailing classes tend not to. When you want to send an email you create the email object populate the address, subject, body, etc. and call the method that send the email. I suspect this is off topic, it's standard OO methodology - the same as in java, python, C++, insert favourite OO language here. Only inherit when you have an ISA relationship. You don't seem to, you just want to use the API of a class - after all you could use a non-OO email module in the same way... Are you planning on inheriting from DBI in order to get database functionality? -- Sam Holden
Re: Subclassing a mailer
* Sam Holden [EMAIL PROTECTED] [2005-01-15 17:09]: Only inherit when you have an ISA relationship. I just want to chime in to agree. Inheritance is greatly overrated and widely abused. It is almost always the very last option you should consider. Aggregation is way underrated and should be used much more often. Regards, -- Aristotle Like punning, programming is a play on words. -- Alan J. Perlis, Epigrams in Programming
Re: Subclassing a mailer
Scott R. Godin wrote: For a project I'm on, I'm pondering whether or not to subclass one of the various Mail::* implementations out there, with an eye for Mail::Mailer. Does anyone have any recommendations in this regard? gotchas things I should watch out for ? pointers? examples? :) I don't understand why you want to subclass Mail::Mailer. You haven't given us enough information. Are you looking to add some functionality not present in any of the mailers? What kind of functionality? Randy.
Re: Subclassing a mailer
On Thu, Jan 13, 2005 at 10:02:32AM -0500, Scott R. Godin wrote: For a project I'm on, I'm pondering whether or not to subclass one of the various Mail::* implementations out there, with an eye for Mail::Mailer. Does anyone have any recommendations in this regard? gotchas things I should watch out for ? pointers? examples? :) I subclassed MIME::Lite::send in order to implement a do not contact list. I check to see if the to, cc and bcc addresses are the on the list and return 'undef' is so. Otherwise, I just call MIME::Lite::send to finish the job. That has worked well for me. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: Subclassing a mailer
Randy W. Sims wrote: Scott R. Godin wrote: For a project I'm on, I'm pondering whether or not to subclass one of the various Mail::* implementations out there, with an eye for Mail::Mailer. Does anyone have any recommendations in this regard? gotchas things I should watch out for ? pointers? examples? :) I don't understand why you want to subclass Mail::Mailer. You haven't given us enough information. Are you looking to add some functionality not present in any of the mailers? What kind of functionality? Randy. ahh no, nothing in that regard.. What I want is to add some of said capabilities to another module that I'm creating that's unrelated to any thing to do with mailing. The object merely tracks some client data. In some instances I'll want to send an e-mail to the address in the client data, if they have supplied one. The body of the mail may be created from a Text::Template or some other source, possibly, but essentially I would like to, at some branch in the end-user code, hand it off to be mailed out, but with certain prerequisites determined by my own object. I'm still teaching myself OOPerl, so I don't know how to define it any clearer than that. a lot of the finished functionality of the complete package I'm trying to write is still in a nebulous state, so some of it is up in the air as well, currently. Does this help any? More or less I want to add Mail::Mailer (or some other similar module) functionality to my package, that will let me send attachments (pdf files, or similar) that will be coupons for birthdays, that the client will have signed up to receive, and additionally, regular mailings of special events. Some of them will be going out snailmail and some going out e-mail as per client preferences. -- Scott R. Godin Laughing Dragon Services www.webdragon.net
RE: Subclassing a mailer
Title: RE: Subclassing a mailer ahh no, nothing in that regard.. What I want is to add some of said capabilities to another module that I'm creating that's unrelated to any thing to do with mailing. The object merely tracks some client data. In some instances I'll want to send an e-mail to the address in the client data, if they have supplied one. The body of the mail may be created from a Text::Template or some other source, possibly, but essentially I would like to, at some branch in the end-user code, hand it off to be mailed out, but with certain prerequisites determined by my own object. IMO this is probably a bad reason to subclass. It sounds much more appropriate to do a HAS-A relationship instead of a IS-A relationship. For instance your code at some point is going to call a method that causes an email to be sent. At that point you would create a MIME::Lite object and use it to create and send the mail as needed. Doing this via ISA semantics doesnt make a lot of sense to me. If you were overriding some behaviour in the mail module it would be a different story. Regards, Yves
Re: Subclassing a mailer
Yves Orton wrote: ahh no, nothing in that regard.. What I want is to add some of said capabilities to another module that I'm creating that's unrelated to any thing to do with mailing. The object merely tracks some client data. In some instances I'll want to send an e-mail to the address in the client data, if they have supplied one. The body of the mail may be created from a Text::Template or some other source, possibly, but essentially I would like to, at some branch in the end-user code, hand it off to be mailed out, but with certain prerequisites determined by my own object. IMO this is probably a bad reason to subclass. It sounds much more appropriate to do a HAS-A relationship instead of a IS-A relationship. For instance your code at some point is going to call a method that causes an email to be sent. At that point you would create a MIME::Lite object and use it to create and send the mail as needed. Doing this via ISA semantics doesnt make a lot of sense to me. If you were overriding some behaviour in the mail module it would be a different story. 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. -- Scott R. Godin Laughing Dragon Services www.webdragon.net
