Mailing List Archive

On 2 Oct 2008, at 17:35, Octavian Rasnita wrote:

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

<snip> list of considerations / thoughts / requirements

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

Ok, but none of this has _any_ relevance to Catalyst. If you build it
right, you can reuse the templates inside and outside Catalyst, but
to be able to do that - you have to explicitly design for Catalyst to
not know / care.

<snip>

> The model-way looks pretty clean and I will try to use this way.

Well, that's how rails does it, so it _must_ be the right approach...

Cheers
t0m

(P.S. I half joke, and I'm half serious above - for the problem
you're solving, being an independent model and using C::M::A is the
right approach).

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

On Thu, Oct 02, 2008 at 03:41:23PM +0300, Octavian Rasnita wrote:
> > 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.

No no no no no no no.

Having a C::V::Email -and- a C::V::Mail will confuse the shit out of newbies
to no gain. Please, please don't do that.

>From what I can see, C::V::Email is responsible for three things:

1 constructing the mail from the input
2 sending the mail once it's constructed
3 processing config and stash to make the arguments to the first two

So far as I can see, you want to provide an alternative for (1) that uses
Mail::Builder, and an alternative for (3) that provides a simpler interface.

Both of these things would be potentially useful in isolation.

So, the answer seems to me to be to make sure C::V::Email's code separates
all three stages, then you can provide a component that overrides (1) and
one that overrides (3) and then a third module that does

use parent qw(
Thing::That::Overrides::One
Thing::That::Overrides::Three
Catalyst::View::Email
);

and NEXT/C3 will dispatch things appropriately for you.

Of course, the ::One overrider would mostly bolt in your external code, so
it'd then be easy to re-use that outside Catalyst.

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

On Thu, Oct 02, 2008 at 03:19:10PM +0200, Eriam Schaffter wrote:
> 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 !

That's why MooseX::JobQueue was written - but ash didn't have time to
clean it up and release it before he left Shadowcat to join a startup.

Volunteers to help finish it up would be -very- welcome.

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

From: "Matt S Trout" <dbix-class@trout.me.uk>
>> 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.
>
> No no no no no no no.
>
> Having a C::V::Email -and- a C::V::Mail will confuse the shit out of
> newbies
> to no gain. Please, please don't do that.

Ok, I won't do that. Using some suggestions from the list and because I have
seen that the interface for accessing a model is nicer, I think I will made
it a model.

So it will be named C::M::Email or C::M::Mail.
This won't confuse the beginners, not only because C::V::Email is a view and
this would be a model, but because the interfaces will be totally different
(because one is a view and the other a model).

In this case, sending an email would be an action just like when saving data
into a database and I hope I could make the interface to look like:

$c->model("Email")->send(from => $from, to => $to, subject => $subject,
htmltext => $html);

Of course, if the old users will have these parameters in
$c->stash->{email}, I hope I will make C::M::Email to be able to be used
also as:

$c->model("Email")->send(@{$c->stash->{email}});

instead of

$c->forward($c->view("Email"));

Actually, I already started to make C::M::Email and it also works, but
unfortunately I can get the parameters only from the MyApp.pm configuration
and from the controller when doing $c->model("Email")->send(...).

But I don't know how to get (in C::M::Email) the parameters set in
MyApp::Model::Email using:

__PACKAGE__->config(
mailer_args => ['SMTP', Host => 'smtp.host.com'],
from => ['me@host.com', 'My Name'],
);

They are not taken into consideration...

I have tried with:

sub new {
my $self = shift;
my ( $c ) = @_;
$self = $self->NEXT::new( @_ );
#For the moment I don't know why I should use the line above...

my $settings = $c->config->{'Model::Email'};
}

Thank you.

Octavian


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

On Sun, Oct 5, 2008 at 4:23 AM, Octavian Rasnita <orasnita@gmail.com> wrote:
> From: "Matt S Trout" <dbix-class@trout.me.uk>
>>>
>>> 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.
>>
>> No no no no no no no.
>>
>> Having a C::V::Email -and- a C::V::Mail will confuse the shit out of
>> newbies
>> to no gain. Please, please don't do that.
>
> Ok, I won't do that. Using some suggestions from the list and because I have
> seen that the interface for accessing a model is nicer, I think I will made
> it a model.
>
> So it will be named C::M::Email or C::M::Mail.
> This won't confuse the beginners, not only because C::V::Email is a view and
> this would be a model, but because the interfaces will be totally different
> (because one is a view and the other a model).
>
> In this case, sending an email would be an action just like when saving data
> into a database and I hope I could make the interface to look like:
>
> $c->model("Email")->send(from => $from, to => $to, subject => $subject,
> htmltext => $html);
>
> Of course, if the old users will have these parameters in
> $c->stash->{email}, I hope I will make C::M::Email to be able to be used
> also as:
>
> $c->model("Email")->send(@{$c->stash->{email}});
>
> instead of
>
> $c->forward($c->view("Email"));
>
> Actually, I already started to make C::M::Email and it also works, but
> unfortunately I can get the parameters only from the MyApp.pm configuration
> and from the controller when doing $c->model("Email")->send(...).
>
> But I don't know how to get (in C::M::Email) the parameters set in
> MyApp::Model::Email using:
>
> __PACKAGE__->config(
> mailer_args => ['SMTP', Host => 'smtp.host.com'],
> from => ['me@host.com', 'My Name'],
> );
>
> They are not taken into consideration...
>
> I have tried with:
>
> sub new {
> my $self = shift;
> my ( $c ) = @_;
> $self = $self->NEXT::new( @_ );
> #For the moment I don't know why I should use the line above...
>
> my $settings = $c->config->{'Model::Email'};
> }
>
> Thank you.
>
> Octavian
>
>

Honestly I don't even see why you would release a
Catalyst::Model::Email, instead just bundle a code snippet that uses
Catalyst::Model::Adaptor.

Don't pollute CPAN with things like Catalyst::Model::YouTube ...
stupid modules that jrockway fortunately deprecated.

-J

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

From: "J. Shirley" <jshirley@gmail.com>>
> Honestly I don't even see why you would release a
> Catalyst::Model::Email, instead just bundle a code snippet that uses
> Catalyst::Model::Adaptor.

I think that a beginner would find easier to install just a module, run a
command for creating a model, then use a single method to send a UTF-8
encoded email, with attachments and images shown in the HTML part of the
message than using C::V::Email and create each part of the message, do the
encoding of headers and add attachments (if possible).

I don't understand why you think that my module won't be helpful for many
beginners and even for the advanced users, because it is easier to use it
for sending email, with one or more attachments, taken from static files or
from templates of different types, template files or from variables...

> Don't pollute CPAN with things like Catalyst::Model::YouTube ...
> stupid modules that jrockway fortunately deprecated.

The model I wanted to do can do more than C::V::Email and easier, so I don't
think it pollutes the CPAN.

If there is another simpler way to send UTF-8 encoded email messages with a
text and an html part, with inline images and attachments from files and
templates, then you are right and I would probably like to use that module,
so please tell me about it.

Thank you.

Octavian


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

On Sun, Oct 5, 2008 at 9:32 AM, Octavian Rasnita <orasnita@gmail.com> wrote:
> From: "J. Shirley" <jshirley@gmail.com>>
>>
>> Honestly I don't even see why you would release a
>> Catalyst::Model::Email, instead just bundle a code snippet that uses
>> Catalyst::Model::Adaptor.
>
> I think that a beginner would find easier to install just a module, run a
> command for creating a model, then use a single method to send a UTF-8
> encoded email, with attachments and images shown in the HTML part of the
> message than using C::V::Email and create each part of the message, do the
> encoding of headers and add attachments (if possible).
>
> I don't understand why you think that my module won't be helpful for many
> beginners and even for the advanced users, because it is easier to use it
> for sending email, with one or more attachments, taken from static files or
> from templates of different types, template files or from variables...
>

Because you don't understand what I'm talking about. That isn't what
I said at all.

>> Don't pollute CPAN with things like Catalyst::Model::YouTube ...
>> stupid modules that jrockway fortunately deprecated.
>
> The model I wanted to do can do more than C::V::Email and easier, so I don't
> think it pollutes the CPAN.
>
> If there is another simpler way to send UTF-8 encoded email messages with a
> text and an html part, with inline images and attachments from files and
> templates, then you are right and I would probably like to use that module,
> so please tell me about it.
>

No, you are just missing the point about my comments about polluting
CPAN. I'm telling you that putting
Catalyst::Model::{YourGlueToYourMailModule} is dumb. The reason is
that your model code would (or, rather, should) be nothing more than:

package MyApp::Model::Email;

use base 'Catalyst::Model::Adaptor';

__PACKAGE__->config( class => 'Mail::Builder::Simple::TT' ); # Or
whatever you end up naming your mail module

1;

__END__

If your model code contains significantly more than that, you're
likely doing it wrong. Catalyst is glue.

If you really think that the glue is worth putting on CPAN, you'll
likely find nearly everybody disagreeing. You can always include a
Catalyst::Helper package that can create the model class via
"myapp_create.pl model Mail Mail::Builder", and that will just
generate the above code.

Since you seem to misunderstand the workflow, here's how I see it and
you can correct me if I'm wrong:
You wanted to decouple your mail delivery mechanism from Catalyst and
essentially wrap Mail::Builder. Hence, the model space so you can
easily use it outside of Catalyst. If you put everything in the
Catalyst::Model namespace, you're doing it wrong. Therefor, it would
be simply Mail::Builder::Simple::TT or whatever. The model class that
Catalyst would use would simply return an instantiated object,
therefor MyApp::Model::Email would be nothing more than
Catalyst::Model::Adaptor-based code.

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

From: "J. Shirley" <jshirley@gmail.com>
> You can always include a Catalyst::Helper package that can create the
> model class via
> "myapp_create.pl model Mail Mail::Builder", and that will just
> generate the above code.

Oh thank you! Finally I understand.

I mean, I understood what you were talking about, but I don't know why I
thought that every view or model has its own helper class, and I couldn't
imagine that I could create just the helper class without creating a model
or a view.

Octavian


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

Hi Matt

Wiadomo¶æ napisana w dniu 2008-10-05, o godz. 12:42, przez Matt S Trout:

> That's why MooseX::JobQueue was written - but ash didn't have time to
> clean it up and release it before he left Shadowcat to join a startup.
>
> Volunteers to help finish it up would be -very- welcome.

Lately I started some deeper digging into Moose, so... if you don't
have any better volunteer around, maybe I could try to do something
useful?

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