Mailing List Archive

Catalyst plugin
Hi,

I've created a Catalyst plugin and I want to upload it to CPAN. Please tell me if it is well to use it as a plugin, or if the suggested name is right.
(It is my first perl module that I want to upload to CPAN.)

I like to send email from Catalyst apps using
$c->email

but the problem with this approach (or many others) is that it is hard to send emails that are UTF-8 encoded, that have a text and an html part, that have one or more attachments, images inline, because I must know more about MIME types and create each part separately specifying the MIME type, the Content-Type, etc.

So I've made a plugin that uses the module Mail::Builder to create the message and Email::Send to send it.
The suggested name would be Catalyst::Plugin::Mail.

I think it could be a plugin, just as C::P::Email, because I think the most easy would be to use it just as C::P::Email, but if you have other suggestions, please tell me.

The interface of this module should be something like:

in MyApp.pm

__PACKAGE__->config(
'mail' => {
mailer_args => ['SMTP', Host => 'smtp.mymail.com'],
#mailer_args => ['Gmail', username => 'user', password => 'pass'],
#mailer_args => ['Sendmail'],
#... other senders supported by Email::Send
mail_args => {
from => 'me@mymail.com',
#from => ['me@mymail.com', 'My Real Name'],
#... and other mail fields like To:, Cc:, Subject:, if wanted
},
},
);

in a controller:

$c->mail(
to => 'you@yourmail.com',
subject => 'The subject (with UTF-8 chars)',
htmltext => '<h1>Hello</h1> world (also UTF-8 encoded)',
);

or:

$c->mail(
from => ['me@mymail.com', 'My Name'],
to => ['you@yourmail.com', 'Your Name'],
subject => 'The subject',
plaintext => 'The plain text',
htmltext => 'The HTML text',
attachment => ['file1.pdf', 'file2.pdf'],
image => ['image1.png', 'image2.png'],
);

or:

$c->mail(
more_to => [
'friend1@mail.com',
'friend2@mail.com',
['friend3@mail.com', 'Name of Friend3'],
],
subject => 'The subject',
htmltext => 'The html text',
);

or:

$c->mail(
mailer_args => ['SMTP', Host => 'mail.another.com'],
from => 'me@another.com',
to => 'you@yourmail.com',
subject => 'The subject',
plaintext => 'Text...',
);

Thank you.

Octavian


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
On Tuesday 30 September 2008 09:31:35 Octavian Rasnita wrote:
> I think it could be a plugin, just as C::P::Email, because I think the most
> easy would be to use it just as C::P::Email, but if you have other
> suggestions, please tell me.

Have a look at Catalyst::View::Email

--
Bogdan Lucaciu
http://www.wiz.ro/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
On 30 Sep 2008, at 07:31, Octavian Rasnita wrote:
> I've created a Catalyst plugin and I want to upload it to CPAN.
> Please tell me if it is well to use it as a plugin, or if the
> suggested name is right.
> (It is my first perl module that I want to upload to CPAN.)

Nice one! :)

> So I've made a plugin that uses the module Mail::Builder to create
> the message and Email::Send to send it.
> The suggested name would be Catalyst::Plugin::Mail.
>
> I think it could be a plugin, just as C::P::Email, because I think
> the most easy would be to use it just as C::P::Email, but if you
> have other suggestions, please tell me.

This *should not* be a Catalyst plugin.

That would specifically exclude anyone from having two email sending
systems configured differently, and that's bad. Also putting stuff
into Catalyst's global namespace when it isn't needed is baad..

This problem used to be most obvious in form builders - a load of
these all too $c->form, meaning that you couldn't have two in the
same application - sucktastic.

Please go and read the section in the manual about extending
Catalyst: http://search.cpan.org/~zarquon/Catalyst-Manual-5.7013/lib/
Catalyst/Manual/ExtendingCatalyst.pod#Plugins

This should make it more clear why you don't want this to be a plugin..

I'd say that the actual templating parts of this should be a View,
and if you need additional functionality in your controllers, it
should be a controller base class..

As someone already pointed out, there is already a
Catalyst::View::Email, maybe you should look to extending / enhancing
that to do what you want?

Cheers
t0m



_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
Hi,

Thank you all for recommending to create a view. I know about C::V::Email but I always prefered to use C::P::Email because it was more simple.
Anyway, probably partly I didn't like C::V::Email because I needed to create the email message manually if it contains attachments, images...

I will try to create a view. I hope I will succeed.

Thank you.

Octavian

----- Original Message -----
From: "Bogdan Lucaciu" <bogdan@wiz.ro>
To: "Development of the elegant MVC web framework" <catalyst-dev@lists.scsys.co.uk>
Sent: Tuesday, September 30, 2008 11:00 AM
Subject: Re: [Catalyst-dev] Catalyst plugin


> On Tuesday 30 September 2008 09:31:35 Octavian Rasnita wrote:
>> I think it could be a plugin, just as C::P::Email, because I think the most
>> easy would be to use it just as C::P::Email, but if you have other
>> suggestions, please tell me.
>
> Have a look at Catalyst::View::Email
>
> --
> Bogdan Lucaciu
> http://www.wiz.ro/
>
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev@lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
On Tue, Sep 30, 2008 at 01:44:49PM +0300, Octavian Rasnita wrote:
> Hi,
>
> Thank you all for recommending to create a view. I know about C::V::Email but I always prefered to use C::P::Email because it was more simple.

C::V::Email is definitely a better approach; email sending really shouldn't
need to be a plugin. Also note that using a plugin means you can only have
one $c->email per app which means you can't re-use code as easily, whereas
you can have several views and different controllers use different ones.

> Anyway, probably partly I didn't like C::V::Email because I needed to create the email message manually if it contains attachments, images...
>
> I will try to create a view. I hope I will succeed.

You should see about patching Catalyst::View::Email instead, I think.

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

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?

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
On Tuesday 30 September 2008 17:23:55 Matt S Trout wrote:
> >From my memory C::V::Email::Template already handles creating the basic
> > mail.
>
> 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 th

You can try using Email::MIME::CreateHTML , it's rather nice

--
Bogdan Lucaciu


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
On Tue, Sep 30, 2008 at 7:23 AM, Matt S Trout <dbix-class@trout.me.uk> wrote:
> On Tue, Sep 30, 2008 at 01:44:49PM +0300, Octavian Rasnita wrote:
>> Hi,
>>
>> Thank you all for recommending to create a view. I know about C::V::Email but I always prefered to use C::P::Email because it was more simple.
>
> C::V::Email is definitely a better approach; email sending really shouldn't
> need to be a plugin. Also note that using a plugin means you can only have
> one $c->email per app which means you can't re-use code as easily, whereas
> you can have several views and different controllers use different ones.
>
>> Anyway, probably partly I didn't like C::V::Email because I needed to create the email message manually if it contains attachments, images...
>>
>> I will try to create a view. I hope I will succeed.
>
> 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.

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.

> >From my memory C::V::Email::Template already handles creating the basic mail.
>
> 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.

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.

-J

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
Hi,

From: "Bogdan Lucaciu" <bogdan@wiz.ro>
> You can try using Email::MIME::CreateHTML , it's rather nice

I have tried, but it doesn't do UTF-8 encoding automaticly for the headers.
That's why I prefer Mail::Builder.

Octavian


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
Hi,

From: "J. Shirley" <jshirley@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@host.com', #or:
to => ['email@host.com', 'Recipient Name'], #or:
more_to => [
'recipient1@host.com',
['recipient2@host.com', 'Name Recipient2'],
],
# "from" could override the "from" that could be defined in config.
from => 'me@host.com', #or:
from => ['me@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


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
On Tue, Sep 30, 2008 at 10:35 AM, Octavian Rasnita <orasnita@gmail.com> wrote:
> Hi,
>
> From: "J. Shirley" <jshirley@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:
>

Lets not work on changing the interface and instead focus on adding
attachment support :)

When sending email, you should always specify content type of the
parts though. If you like the htmltext aspects of Mail::Builder,
there are other ways (convenience methods, etc), but they would
possibly require further upstream changes with
Catalyst::View::Email::Template (which uses TT to generate HTML) --
and I don't want to automatically assume that TT => HTML, but I'm fine
with a simple configuration switch, but if your only complaint is that
you don't want to set your specific content type, I think it is best
to shelve that until after the attachment work.

> $c->stash->{email} = {
[. snip, I don't want to discuss interface changes right now, lets just
focus on attachments]
> attachment => 'file_name', #or:
> attachment => ['file_name1', 'file_name2'],
> image => 'image.png', #for displaying an inline image
> mailer_args => ['SMTP', Host => 'mail.host.com'],
> };

Images aren't the only thing that can be embedded, and the inline
aspect can be a bit tricky to get right. This is why
Email::MIME::CreateHTML looks the most advantageous for handling
embedding media.

If we drop that case, and then just focus on handling:
$c->stash->{email}->{attachment} = [ 'file1', 'file2' ]; # (or just a
simple scalar)

>
> 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],
>

Right, but that doesn't answer embedded images. Adding an attachment
is very simple. It is just another part that goes into Email::MIME.

If you just chuck an attachment in the parts, it should DTRT and send
the attachment. In that regard, Catalyst::View::Email already does
handle attachments. The only step is to have a simpler syntax and
handle embedded images.

Here's an example that should work:

$c->stash->{email}->{parts} = [.
Email::MIME->create(
attributes => {
filename => "report.pdf",
content_type => "application/pdf",
encoding => "quoted-printable",
name => "2004-financials.pdf",
},
body => io( "2004-financials.pdf" )->all,
),
];

The problem with your syntax above is that it doesn't handle the
content_type (we can infer, so no big deal), the encoding (again, we
can infer), the filename and name aspects shouldn't be tightly
married, either.

This is the issue with Email by and large. The syntax is either too
simple for most cases, or too complex for most cases.

Having something like $c->stash->{email}->{attachments} = [
'filename.pdf' ] is fine with me, assuming that the patch is just
something along these lines:

my @parts = @{ $stash->{parts} };
foreach my $attachment ( @{$stash->{attachments}} ) {
push @parts, Email::MIME->create(
attributes => {
filename => $attachment,
content_type => infer_mimetype( $attachment ),
encoding => "quoted-printable",
name => $attachment,
},
body => io( $c->path_to($attachment) )->all,
),
}


> 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',
> };
>

That's a separate issue then. Try first, if it fails, submit an RT
request. The patch may be to move to Mail::Builder, but Mail::Builder
is just yet another wrapper on top of MIME::Tools, whereas Email::Send
is on the Email::* modules. I have more familiarity with the Email::*
modules and that makes me more comfortable. If you want to switch to
Mail::Builder, you'll need to provide ample reasoning and prove that
there is valid reasons to do so. I don't want to migrate away from
PEP without just cause.

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

Actually, it encodes subject and organization to MIME-Header RFC 2047.
This would be a reasonable -separate- patch to C::V::Email to
encode('MIME-Header', $subject), as per Mail::Builder (I didn't check
if Email::Stuff did this, but I would assume so because it seems a
more PEP-friendly version of Mail::Builder).

I don't see where it is automatically encoding the body, if you can
point out in the Mail::Builder source I'd appreciate it. It's
automatic conversion from htmltext to plaintext is also not desirable
to me, but perhaps others would like it -- this is a call for
comments.

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

Catalyst::View::Email already uses Email::Send. Hence, all the
mailers. Catalyst::View::Email is a wrapper on top of Email::*
modules, most notably Email::Send and Email::MIME.

If you're serious about participating, I would recommend you RTFS
Catalyst::View::Email, Mail::Builder and Email::Stuff.


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

You have 3 different things going on here. Lets break them down.

#1 is the attachments
#2 is moving to a higher level Email::Stuff or Mail::Builder setup,
which should be very seriously considered.
#3 is your API changes, which I don't even want to get into until #1
and #2 are done.

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

I'm strongly resistant to API changes without a lot of merit to them
(things like "more_to" or having default sender status in config will
likely never get by me.) Just a heads up.

-J

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
On Tue, Sep 30, 2008 at 12:23:09PM -0700, J. Shirley wrote:
> I'm strongly resistant to API changes without a lot of merit to them
> (things like "more_to" or having default sender status in config will
> likely never get by me.) Just a heads up.

Though I'd say patches to make it possible to -subclass- to add that sort
of stuff should be ok.

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
Hi,

From: "J. Shirley" <jshirley@gmail.com>
> Lets not work on changing the interface and instead focus on adding
> attachment support :)

Well, I am mainly interested not on adding attachments support, but on 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.

With other words, I am interested in a less flexible module, but one much easier to use.

If C::V::Email would allow adding attachments and images, but would also allow adding Flash annimations in the HTML content, or other objects, or it would also allow other encodings than UTF-8, but it would require all those parameters manually (the encoding, the Content-Type), I won't use it, not because the module is not good, but because it might be too much for what I need.

> When sending email, you should always specify content type of the
> parts though. If you like the htmltext aspects of Mail::Builder,
> there are other ways (convenience methods, etc), but they would
> possibly require further upstream changes with
> Catalyst::View::Email::Template (which uses TT to generate HTML) --
> and I don't want to automatically assume that TT => HTML, but I'm fine
> with a simple configuration switch, but if your only complaint is that
> you don't want to set your specific content type, I think it is best
> to shelve that until after the attachment work.

Actually, I would also like that the same module to work with templates if it is possible.
So instead of using
body => ...
to use
template => ...

but with the same module, without needing to install another module, nor create another view, configure it and so on.

And to be more clear what I want, is to create a static module that works outside of Catalyst app, and use that module in the Catalyst view, because I want to be able to use the same interface when sending mail from a cron job, so probabily the part of the module that uses a template should not use Catalyst but Template-Toolkit directly.

So, in this case, don't you think it would be better to create another module?

Octavian


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
On Wed, Oct 01, 2008 at 10:15:47AM +0300, Octavian Rasnita wrote:
> And to be more clear what I want, is to create a static module that works outside of Catalyst app, and use that module in the Catalyst view, because I want to be able to use the same interface when sending mail from a cron job, so probabily the part of the module that uses a template should not use Catalyst but Template-Toolkit directly.
>
> So, in this case, don't you think it would be better to create another module?

As I said in another email, what I'd say is that you should -subclass-
C::V::Email or C::V::Email::Template, and if you can't do what you need via
subclassing, sort out patches to the existing stuff so you can subclass it.

Then the stuff you want is in your own module, but all the stuff the already
existing modules already do isn't duplicated.

Ain't OO awesome :)

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
On Wed, Oct 1, 2008 at 5:45 PM, Matt S Trout <dbix-class@trout.me.uk> wrote:
> On Wed, Oct 01, 2008 at 10:15:47AM +0300, Octavian Rasnita wrote:
>> And to be more clear what I want, is to create a static module that works outside of Catalyst app, and use that module in the Catalyst view, because I want to be able to use the same interface when sending mail from a cron job, so probabily the part of the module that uses a template should not use Catalyst but Template-Toolkit directly.
>>
>> So, in this case, don't you think it would be better to create another module?
>
> As I said in another email, what I'd say is that you should -subclass-
> C::V::Email or C::V::Email::Template, and if you can't do what you need via
> subclassing, sort out patches to the existing stuff so you can subclass it.
>
> Then the stuff you want is in your own module, but all the stuff the already
> existing modules already do isn't duplicated.
>
> Ain't OO awesome :)
>

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

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

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

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
Hi,

From: "J. Shirley" <jshirley@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


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
From: "Matt S Trout" <dbix-class@trout.me.uk>
> As I said in another email, what I'd say is that you should -subclass-
> C::V::Email or C::V::Email::Template, and if you can't do what you need via
> subclassing, sort out patches to the existing stuff so you can subclass it.
>
> Then the stuff you want is in your own module, but all the stuff the already
> existing modules already do isn't duplicated.
>
> Ain't OO awesome :)

Oh yes it is if you know to use it well enough. :-)

Maybe those 2 modules could be sub-classed and use the external module I've made, but I think that sub-classing will mean just a bigger effort without any benefit.

Why? Because I want to change:
- the interface used by the users ($c->stash->...)
- the structure of the configuration hash (that might allow defining more servers)
- the module that will create the message elements
- The way it will handle the templates (They will be also handled by the external program)

And this will mean changing everything.

Octavian


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
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


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
On 2 Oct 2008, at 07:53, Octavian Rasnita wrote:

> From: "Matt S Trout" <dbix-class@trout.me.uk>
>> As I said in another email, what I'd say is that you should -
>> subclass-
>> C::V::Email or C::V::Email::Template, and if you can't do what you
>> need via
>> subclassing, sort out patches to the existing stuff so you can
>> subclass it.
>>
>> Then the stuff you want is in your own module, but all the stuff
>> the already
>> existing modules already do isn't duplicated.
>>
>> Ain't OO awesome :)
>
> Oh yes it is if you know to use it well enough. :-)

Well, if you'd listened - people have already told you the
appropriate design for what we think you're trying to do, and I'm
sure that getting SVN space so that the project is public, and
someone to help review and help you with design problems in your code
is very possible. The author of Catalyst::View::Email has already
stated that he'll help support your goals..

> Maybe those 2 modules could be sub-classed and use the external
> module I've made, but I think that sub-classing will mean just a
> bigger effort without any benefit.

I think you've got what Matt is talking about totally backwards here..

The idea is that you make Catalyst::View::Email able to do all the
features you want, and enable it to process something which isn't the
stash (in the same way you can call $c->View('TT')->process yourself
manually - I'd recommend the same interface as it's familiar to people).

You then sub-class it, and change:
>
> Why? Because I want to change:
> - the interface used by the users ($c->stash->...)
> - the structure of the configuration hash (that might allow
> defining more servers)

Problem solved...

> - the module that will create the message elements

Why were you doing this again?

> - The way it will handle the templates (They will be also handled
> by the external program)

So this was a feature addition / abstraction to the current
Catalyst::View::Email?

> And this will mean changing everything.

I totally disagree..

You're correct, however, when you say that it's more work to build
flexible re-useable code which is actually useful to a wide user
community. It _is_ more work, quite a _lot_ more work than just
writing something to do what you need right now. Documenting it well
enough for people to use it without having to resort to reading the
code is even harder.

But the end solution is vastly superior than a 'one shot wonder', and
as you're writing less, better thought out code (as you're sharing as
much code as possible, and having to arrange code so that it _can_ be
shared) - and guess what, the less lines of code you have, and the
more carefully planned/designed for reuse your code is, the less bugs
you have, and the more people can reuse it to solve _their_ problems
(which won't be quite the same as yours)..

If you want to build your own little email solution which works
exactly how you like, then please go ahead. Just please don't put it
on CPAN as a catalyst component, as it won't have been built to be
useful to anyone but you...

I'm sorry if this sounds harsh, and I'm not trying to criticse - but
there is no point contributing to CPAN unless you are actually
building something someone else could use, and there is so much
confusion about what problem you're actually trying to solve here (as
you don't seem to have decided that yourself) that the current end
result is unlikely to solve any problem in a reasonable fashion.

Cheers
t0m


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
From: "Tomas Doran" <bobtfish@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


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
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


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
Le Jeu 2 octobre 2008 14:41, Octavian Rasnita a écrit :
> 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.

That's why I finally built a job queue so Catalyst does not have to deal
with trapping smtp server errors, trying to resend emails and so on.

It just leave that stuff to the email sending job (in the background
running job queue) and can focus on delivering the view to the user.

And also, having a jobqueue is always handfull !



_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
From: "Eriam Schaffter" <eriam@eriamschaffter.info>
> That's why I finally built a job queue so Catalyst does not have to deal
> with trapping smtp server errors, trying to resend emails and so on.
> It just leave that stuff to the email sending job (in the background
> running job queue) and can focus on delivering the view to the user.
> And also, having a jobqueue is always handfull !

Is it Catalyst::JobQueue::Job?

If yes, are there any examples for using it for sending email?

Thanks.

Octavian


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
On Thu, Oct 2, 2008 at 8:44 AM, Octavian Rasnita <orasnita@gmail.com> wrote:
> From: "Eriam Schaffter" <eriam@eriamschaffter.info>
>>
>> That's why I finally built a job queue so Catalyst does not have to deal
>> with trapping smtp server errors, trying to resend emails and so on.
>> It just leave that stuff to the email sending job (in the background
>> running job queue) and can focus on delivering the view to the user.
>> And also, having a jobqueue is always handfull !
>
> Is it Catalyst::JobQueue::Job?
>
> If yes, are there any examples for using it for sending email?
>
> Thanks.
>
> Octavian
>
>

If you want a standalone JobQueue, TheSchwartz works and has an Email
sender worker on CPAN that coalesces based on domain.

There is also MooseX::JobQueue at
http://code2.0beta.co.uk/moose/svnweb/index.cgi/moose/browse/MooseX-JobQueue/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
From: "Tomas Doran" <bobtfish@bobtfish.net>

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

Well, not exactly. I know what I want to do, but I don't know exactly how.

Until now, I had a Mail::Builder::Simple that creates the message and sends
it using Email::Send.
And I also had a wrapper Mail::Builder::Simple::TT that uses
Mail::Builder::Simple and Template-Toolkit for creating the parts that use
templates.

So in the Catalyst module I wanted to use Mail::Builder::Simple::TT for
beeing able to interpret templates if the user needs that, but it is not
well, because maybe some templates use Mason or HTML::Template.

So now I want to make somehow the base modules in such a way so I need to
access Mail::Builder::Simple only, and if this module will see that the user
uses a template, it should require Mail::Builder::Simple::TT or
Mail::Builder::Simple::Mason or another one.
And if somebody will want, he could create another module
Mail::Builder::Simple::AnotherTemplate.

I could get a way of doing this, but I would like to do it as clean as
possible, for example if I will find that a template uses TT,
Mail::Builder::Simple should require Mail::Builder::Simple::TT with the
default options, but it would be nice to load the ::TT module only if it
finds that it needs it for parsing a TT template, and it would be also nice
if it would create the $template object only once if possible, for a better
speed.

And if I would send a mail message to many email addresses, it would be also
nice if the message would be created only once, or at least the parts of the
message which are not modified for each receiver.

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

That's what I was thinking but I couldn't express it very well.

Thank you for your help and suggestions.
The model-way looks pretty clean and I will try to use this way.

Octavian


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Catalyst plugin [ In reply to ]
From: "J. Shirley" <jshirley@gmail.com>
> If you want a standalone JobQueue, TheSchwartz works and has an Email
> sender worker on CPAN that coalesces based on domain.
>
> There is also MooseX::JobQueue at
> http://code2.0beta.co.uk/moose/svnweb/index.cgi/moose/browse/MooseX-JobQueue/

I was afraid I will hear about TheSchwartz. Unfortunately I need to use
Windows and I couldn't install it under this wonderful OS.

I will check MooseX::JobQueue.

Thanks.

Octavian


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

1 2  View All