[Catalyst-dev] Catalyst plugin

[Octavian Rasnita]

Hi,

From: "J. Shirley" <jshirley at gmail.com>
> The UTF-8 headers is a patch to just run encode('MIME-Header',
> $subject), so that's negligible.
> 
> It'd be pretty simple to have the template => stuff automatically call
> htmltext anyway.  Just subclass C::V::Email::Template and overload
> generate_parts... but that isn't everything.  I wouldn't want to
> assume that anything template based is html, but that's just me (I'd
> rather write one line of code to set the content_type and know for
> sure).

As I said, I want to make something as easy as possible to use, with as few as possible code to write and I don't want to be very flexible and to allow absolutely everything.

> Since you said you want a module outside of the Catalyst cycle it
> sounds like what you want is something that just runs TT and puts the
> output in htmltext in Mail::Builder.  That's pretty trivial, but
> splicing it into the Catalyst request cycle may not "fit" well.
> 
> Catalyst::View::Email::Template isn't married to TT, and shouldn't be.
> It operates on a Catalyst::View object that is template based (Mason,
> TT, etc).

I've seen how C::V::E::Template is made, but I see that it depends on Catalyst so I would need to make 2 separate modules for doing the same thing, one that works in the Catalyst app and one that works outside, and this is not OK.
Even if the Catalyst view would be just a wrapper for a separate module, if it would be using $c to get the variables set by the application, I think it could do exactly the same thing as in case it would be using a Catalyst View for creating the templates.

What I am thinking now is to allow using a template by providing a scalar reference to htmltext or plaintext stash keys instead of the text that should appear in the message. Something like:

plaintext => \'text.tt',

This way it won't be necessary to use the "template" key.

At least now, the view I made yesterday allow specifying the content-type and alternative name for attachments, and maybe I will be able to do the same thing for the templates, and allow adding templates which are not html or text.

Now the attachments can be added using:

attachment => 'file1.doc',
or
attachment => ['file1', 'file1.doc'], #with the name that will appear
or
attachment => ['file', 'file1.doc', 'application/x-msword'], #also specify a Content-Type

If somebody will want to attach a pdf file which is created using a template, I think I can make it to allow using:

attachment => [\'pdf.tt', 'file.pdf', 'application/pdf'],

This will make necessary to specify the content-type only in the special cases.

> It really just seems that you want is 3 lines of code that just joins
> TT and Mail::Builder, which would be fine as a model class (especially
> since your TT config would likely be different than your core Catalyst
> app anyway).
> 
> I could be wrong about the end result, but it seems this is roughly
> what you want:
> my $tt = Template->new;
> my $output;
> $tt->process("template.tt", $stash, \$output);
> $mail->htmltext($output);

Yes, something like that.
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.

Mail::Builder::Simple uses Mail::Builder and Email::Send to send a message that doesn't use a template. It also allow the interface that allows adding more to, cc, bcc, attachments and images using an arrayref of arrayrefs.

Creating the module as a model would be fine, especially that I see the mail sending as an action, as a command, and not something that can be associated with a view, but I have no idea how to write it as a model, so a view is fine.

Octavian