[Catalyst-dev] Catalyst plugin

[Octavian Rasnita]

Hi,

From: "J. Shirley" <jshirley at gmail.com>
>> You should see about patching Catalyst::View::Email instead, I think.
>>
>
> Yes, definitely.  It's admirable to want to contribute to open source,
> CPAN, etc.  It is less noble to think the only way to do this is to
> step on the toes of others and reinvent wheels.  I've always been very
> open to patches on C::V::Email, and since email is a very big part the
> more eyes and hands on it the better.
>
> If you just go off and write your own, you'll likely miss several key
> things, or just outright fork the code and nobody wins.  If there is
> something you distinct that you don't like about it (I understand some
> people don't like the setup in stash, but that can be done away with
> via simple methods that abstract that away) then discuss that and see
> if we can come up with a solution.

I also don't like the thing that we must use the stash very much, but I can 
live with it.
What I am searching for is a module that allows me to send UTF-8 encoded 
emails (body and headers) without needing to specify MIME types, 
Content-Type, without using the Encode module, and of course allow me to add 
attachments and send it with a text and an html part.
That's why I think Mail::Builder is better because it can do these things 
easy.

I can try to change the way C::V::Email creates the message if you think 
this is OK, but if you think it is not, then I think I need to create 
another module.

I also think the interface should allow us using something like:

$c->stash->{email} = {
  # "to" and "more_to" will be added to "to" and "more_to" defined in the 
config, and same for cc and bcc
  to => 'email at host.com', #or:
  to => ['email at host.com', 'Recipient Name'], #or:
  more_to => [
    'recipient1 at host.com',
    ['recipient2 at host.com', 'Name Recipient2'],
  ],
  # "from" could override the "from" that could be defined in config.
  from => 'me at host.com', #or:
  from => ['me at host.com', 'My Name'],
  subject => 'The subject',
  #and other fields like replyto, returnpath, priority...
  plaintext => $plaintext, #or the key could be just "text"
  htmltext => $html, #or it could be just "html"
  attachment => 'file_name', #or:
  attachment => ['file_name1', 'file_name2'],
  image => 'image.png', #for displaying an inline image
  mailer_args => ['SMTP', Host => 'mail.host.com'],
};

All the mail fields could be defined in the config if the site admin wants 
that, including the subject, to and mail body, and in that case, sending 
mail would require just
$c->forward($c->view('Email'));
Of course, that won't be very helpful, but the system would be very 
flexible.
And the mailer_args could be specified not only in the config but when 
putting the mail fields in the stash also, at the same level of the hash 
reference, because it is possible.

> Regarding attachments, it's been on the roadmap (and documented as
> such in the pod) for a while but none of the contributors nor myself
> have had a need for attachments so it simply hasn't gotten done.

If we would use Mail::Builder, it would be very simple to add attachments 
because we would just need to add

attachment => 'file_name'
or
attachment => [$filename1, $filename2, $filename3],

>> >From my memory C::V::Email::Template already handles creating the basic 
>> >mail.

I haven't tried it, but I am almost sure it doesn't handle UTF-8 encoded 
headers well, so if I would use the following code, the message won't be 
well formatted:

$c->stash->{email} = {
#...
subject => 'To Octavian Râsnita',
};

>> Maybe by porting the mail sending code to either Mail::Builder or 
>> Email::Stuff
>> you could achieve something where you can send attachments in the stash, 
>> and
>> maybe have a syntax to get the mime addresses for images - something like
>> adding $c->stash->{image_link} as a sub that resolves that so then in 
>> your
>> template you can do [% image_link('foo.jpg') %} for
>> $c->stash->{attachments}{foo.jpg} or something like that?
>>
>
> Yes.  Email::Stuff wasn't at a point where I wanted to use it for
> C::V::Email, but that has changed.  I would much prefer to move to
> Email::Stuff at the same time of the attachments.
>
> As Bogdan said, we can use Email::MIME::CreateHTML if a single part is
> html (most likely derived from a template).  I think this is somewhat
> separate of an issue than simple attachments.  It may just be a worthy
> patch to move to Email::MIME::CreateHTML in the case of
> Email::Template and handle that outside of the main attachment loop.
>
> This is also my concern with moving to something like Email::Stuff or
> Mail::Builder (Email::Stuff being my preference) -- if there are edge
> case behaviors (send HTML mail, with separate attachments, etc) I
> don't know how the code will end up.

The advantage of Mail::Builder is that it automaticly encodes to UTF-8 the 
headers and the mail body, and one more thing... it gets easier the mail 
fields if they contain only a scalar (such an email address), or an arrayref 
(such a [$email, $name]).

Then the created message could be sent directly with Email::Send and this 
has the advantage of beeing able to use more mailers.

> In any case, I'm happy to have as many contributors as possible.  I'll
> setup branches and hand out commit bits.  I do not hand out comaint
> for CPAN releases until I'm sure the work is of suitable quality to be
> released without me or others blessing it.

Ok, what's next? What should I do to start improving C::V::Email?
Do you agree with my suggestions?

I think they are improvements and they won't affect new users, but the 
problem is that the old code that probably uses other modules for creating 
the messages body might not work well.

Only in that case I would need to start writing a new module.

Octavian