[Catalyst-dev] Catalyst plugin

Tomas Doran bobtfish at bobtfish.net
Thu Oct 2 11:07:07 BST 2008


On 2 Oct 2008, at 07:45, Octavian Rasnita wrote:
>>
>> 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.

The topic of this thread is 'Catalyst plugin'. When we started, you  
wanted to make something that would poop onto Catalyst's global  
namespace.. If you're now talking about writing an email sending  
module (which is 100% decoupled from Catalyst), then go right ahead -  
but it's not really relevant discussion here.

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

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

Err, yes - views are view like..

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

Ugliest interface ever.

Why go one up and make the value a glob, and you can put the template  
name in the scalar slot, and the data you want interplolated in the  
template in the hash slot, and any custom headers you'd like to add  
in the array slot?

So:
use Symbol;
$c->stash->{email_stuff} = gensym;
${ *{ $c->stash->{emailstuff} } } = 'Hi [% username %]';
%{ *{ $c->stash->{emailstuff} } } = ( username => 'fred' );
etc..


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

Is that what you've decided to call it? I guess so as it doesn't  
exist already..

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

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

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

You inherit from Catalyst::Model, and then call $c->model('MyModel')- 
 >method, it's not hard..

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

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

Cheers
t0m




More information about the Catalyst-dev mailing list