[Catalyst-dev] Catalyst plugin

[Tomas Doran]

On 2 Oct 2008, at 13:41, Octavian Rasnita wrote:
> If this is a good goal when sending the email from Catalyst, I  
> think it would be a good goal to do the same thing when sending the  
> mail using a cron job.
> I even seen a recommendation to not put business logic in the  
> controllers, for beeing able to use external apps for adding/ 
> selecting records from the database.
> I think that sending email using the same type of interface from an  
> external program could be also helpful.

Totally agree :)


>>> Actually, Catalyst::View::Mail will use Mail::Builder::Simple::TT,
>>> which wraps Mail::Builder::Simple and Template-Toolkit.
>>> This is not Ok yet, because it doesn't allow using another
>>> templating system, so I need to change some things.
>>
>> Is that what you've decided to call it? I guess so as it doesn't
>> exist already..
>
> Yes. I have previously asked the author of Mail::Builder if he  
> thinks it is a good idea to create Mail::Builder::Simple and he  
> said yes. He also recommended me to name the module that uses TT  
> Mail::Builder::Simple::TT.
> But as I said, I want to change some things for making the module  
> able to use other templating systems.
>

Ok, so you're all sorted on that front then?

>
> I thought that if the mail message is created with Mail::Builder,  
> the name Catalyst::View::Mail could be a good name for the module.
> In order to be as simple as possible, I thought it would be more  
> simple to use just "mail" as a stash key as a default, and just  
> "mail" instead of a name composed by 2 parts in the configuration  
> file.





>> Also, was there a specific reason why you're not planning to reuse
>> code from / share code with Catalyst::View::Email - as it seems to me
>> like both modules could benefit, and you're just re-inventing a wheel
>> here..
>
> I'm not sure I know how to do that.
> I think that if I will sub-class C::V::Email, my module should be  
> able to use the interface of C::V::E also.
> But I will try to see if I find a way of doing this.

No, the entire point in sub-classing it is that you can change the  
interface if you want to..

You may need to do some work on C::V::Email to make that possible /  
easy, but there's nothing to stop you doing it.

>
>> Given that you've noted you want to use this outside Catalyst, why
>> not just write it outside catalyst, and then use
>> Catalyst::Model::Adaptor to glue it to your application.. You end up
>> saying $c->model('MyEmailSend')->build_and_send_email($c->stash->
>> {email});
>
> It is also a good idea. If I will see that I am not able to sub- 
> class C::V::E, I will try to create it as a model in that way.
>
> I hope that I will be able to use
> $c->model("Mail")->send(...);
>
> I mean... "Mail" or "Email"... it doesn't matter, but I don't want  
> to need using
> $c->model("Mail::Builder::Simple")->send();
>
> If I read the POD doc correctly, I can change the class name in the  
> app config file. And if I can do that, I guess I could also do it  
> in the model which will be created by a helper.
>

The name of the model in Catalyst is purely related to the package  
name in MyApp/Model/Foo.pm



>> I think that you need to actually decide what your goals are, and re-
>> state them in simple bullet point form, as you seem to be in (at
>> least) two minds about what you're doing here..
>
> Ok, maybe you are right. I think I want:
>
> - To have an external module that glues Mail::Builder and  
> Email::Send and sends simple mail messages, UTF-8 encoded (body and  
> headers), send simple text messages, or text and html multipart  
> messages, add one or more attachments and inline images, specify an  
> alternative name or Content-Type for attachments but only if they  
> should be uncommon;
>
> - To be able to use a simple interface change in order to specify  
> that some mail fields are not text scalars, but references to  
> templates;

Ok, so that's one standalone project.

If you design your interface so that you say:

my $email = My::Email::Module->new(email_server => [qw/mail pop3/]);  
# Just static / config settings here.
$email->send_email(%all_the_dynamic_params_here);

Or something similar (i.e. ensure you separate the config from the  
actual sending), then it's trivial to use Catalyst::Model::Adaptor to  
glue your module into a Catalyst model.

> - Create a Catalyst view or model that just uses the external  
> module and pass to it the vars from the app config file, or the  
> vars added in the stash, or as parameters...

Your model doesn't want to know about the stash, as then it's  
becoming tied to catalyst.. With Catalyst::Model::Adaptor then your  
class' new method will be passed all the catalyst config, and you  
then have a 'send_email' or whatever method which you invoke with all  
the params you need. (E.g. $c->model('Email')->send_email(%{ $c- 
 >stash->{email} }) or similar)

> I know that the compatibility with C::V::E is not on my list of  
> needs, but if I see that I could sub-class this module, I will do it.


No, don't.

If you're building an email module which is external to Catalyst and  
just glued in as a model (which sounds like a pretty good approach),  
then I don't think you're going to get to share code with  
C::V::Email, but (as discussed above), you're already going to be  
using/re-using several other modules, so it's all good..

Cheers
t0m