[Catalyst-dev] Catalyst plugin

[Octavian Rasnita]

From: "Tomas Doran" <bobtfish at bobtfish.net>
> Please feel free to go and do that, there aren't enough modules in  
> the Email:: namespace already which do what the author wanted, but  
> nobody else uses...
> 
> I'm going to assume I've misread the above, or got confused, and you  
> still mean your (only) goal is 'using UTF-8 chars in the headers  
> without needing to specify the encoding and on creating a multipart  
> message with a text and an html part, but without needing to create  
> each part manually.'
> 
> Which totally made sense, and was a laudable goal..

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.

>> 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.

> Given that your goals (as I quoted above from another email in the  
> thread) are deliberately limited in scope so as to make the module  
> simple to use, would it not make sense to call it  
> Catalyst::View::Email::Simple or something? I guess not if you're not  
> inheriting from Catalyst::View::Email, but I still think the current  
> name is ambiguous..

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.

> 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.

> 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;

- 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...

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.

Octavian