Re: [Catalyst] Using the Catalyst Makefile to install

[Bill Moseley]

On Mon, Mar 11, 2013 at 1:29 PM, Alejandro Imass
wrote:


>
> > This pre-dates Module::ShareDir.
> >
>
> So the templates, images (i.e. the /root) are considered shared data?
>

When I was converting our Catalyst apps to use Dist::Zilla I looked at
changing where Catalyst looks for /root -- just so I could use
Module::ShareDir (supported by Dist::Zilla) and not have to rewrite
Module::Install::Catalyst.

I think I had some discussion of these back in July:
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/msg13186.html

In the end I did implement the code to copy in the /root (and other files
and dirs) into blib just like Module::Install::Catalyst does.

And the configuration file should go for example in /etc in Debian and
> /usr/local/etc on FBSD??
>

We deploy with RPM.

FWIW, this is something we discussed at work quite a bit.  Operations
wanted config in standard location, but we wanted config with the
application.  In general, of our config is more constants that config and
so there's rarely changes to our app config.  Plus, having config with the
app makes it a bit easier to have multiple copies installed.  (In the past
used symlinks to point to live version.)

In other words, the bulk of our config is more like static data, so placing
in share would be ok.

What we did in the end to make the site operations team happy was update
our config system to look in /etc/$app_name/config.yml for an extra config
file that would override (merge with) the app's config.

Our config loads config.yml filrst, then it loads and merges any
mode-specific (i.e. qa, staging, production) config, then finally looks for
/etc/$app_name/config.yml.

Some day we will look more closely at centralized configuration tools --
Puppet and Chef, for example.

-- 
Bill Moseley
mose...@hank.org
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Catalyst with HTTP authentication

[Lukas Thiemeier]

I realized that you don't even have to set password_field correctly.
Something was going terribly wrong in my head, sorry for that.
Only "password_type" has to be set to "self_check", but this is documented.

This means that there is no tricky part at all. Just configure both
modules as described in their documentation.

Lukas

On 03/11/2013 07:54 PM, Lukas Thiemeier wrote:
> Hi,
> 
> I just had some time to try it: C::Authentication::Credential::HTTP and
> C::Authentication::Store::Htpasswd work together just fine. Here is my
> setup:
> 
> in TestApp.pm:
> 
> use Catalyst qw/
> ConfigLoader
> Authentication
> /;
> 
> __PACKAGE__->config(
> "Plugin::Authentication" => {
> realms => {
> default => {
> credential => {
> class => 'HTTP',
> type => "basic",
> password_field => 'check_password',
> password_type => 'self_check',
> },
> store => {
> class => 'Htpasswd',
> file => "/tmp/htpasswd",
> },
> },
> },
> },
> );
> 
> 
> and in Controller/Root.pm (or wherever you need it):
> 
> sub index :Path :Args(0) {
> my ( $self, $c ) = @_;
> $c->authenticate;
> 
> if($c->user_exists){
> $c->res->body("logged in");
> }
> }
> 
> The tricky part is that you have to set "password_field" and
> "password_type" correctly, which is not documented. (You have to know
> how Catalyst Authentication works and read the docs for Authen::Htpasswd
> to find out)
> 
> I still recommend to use C::A::Credential::Remote. Let the server do the
> job, and keep your application small and simple.
> 
> Plus: You can add digest authentication,  certificate authentication,
> kerberos authentication and whatever your server supports without
> modifying your application.
> 
>  Lukas
> 
> 
> 
> On 03/11/2013 03:10 PM, Robert Rothenberg wrote:
>> I have a project that requires using HTTP authentication.
>>
>> There is a Catalyst::Authentication::Credential::HTTP module, but from the
>> documentation, it does not seem to support using htpasswd files, which I
>> need, because a separate web site will be using that file.
>>
>> There is Catalyst::Authentication::Store::Htpasswd, but it does not work
>> with Catalyst::Authentication::Credential::HTTP.
>>
>> I'm not clear on how to do this, without having to write my own handlers for
>> HTTP authentication.
>>
>>
>> ___
>> List: Catalyst@lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
> 
> 
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Using the Catalyst Makefile to install

[Alejandro Imass]

On Sun, Mar 10, 2013 at 4:20 PM, Tomas Doran  wrote:
>
> On 8 Mar 2013, at 04:57, Francisco Obispo  wrote:
>
>> They are installed by default under the lib/ directory, I'm not a big fan of 
>> that setup,
>
> Nobody is a big fan of this setup.
>

I don't think the problem is so much the destination of the lib files.
IMHO they should be installed in the local or site perl directories
amongst any other local CPAN modules.

Where I see the problem is that the current installation ignores all
non-library files completely (the app root directory and the config
file), plus any other data files the app should need.

> This pre-dates Module::ShareDir.
>

So the templates, images (i.e. the /root) are considered shared data?

And the configuration file should go for example in /etc in Debian and
/usr/local/etc on FBSD??

And if the app needs some other files for example a sqllite db file,
where would those go? /var/lib/db ?
How about Windows, how does work there?


--
Alejandro Imass

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Catalyst with HTTP authentication

[Lukas Thiemeier]

Hi,

I just had some time to try it: C::Authentication::Credential::HTTP and
C::Authentication::Store::Htpasswd work together just fine. Here is my
setup:

in TestApp.pm:

use Catalyst qw/
ConfigLoader
Authentication
/;

__PACKAGE__->config(
"Plugin::Authentication" => {
realms => {
default => {
credential => {
class => 'HTTP',
type => "basic",
password_field => 'check_password',
password_type => 'self_check',
},
store => {
class => 'Htpasswd',
file => "/tmp/htpasswd",
},
},
},
},
);


and in Controller/Root.pm (or wherever you need it):

sub index :Path :Args(0) {
my ( $self, $c ) = @_;
$c->authenticate;

if($c->user_exists){
$c->res->body("logged in");
}
}

The tricky part is that you have to set "password_field" and
"password_type" correctly, which is not documented. (You have to know
how Catalyst Authentication works and read the docs for Authen::Htpasswd
to find out)

I still recommend to use C::A::Credential::Remote. Let the server do the
job, and keep your application small and simple.

Plus: You can add digest authentication,  certificate authentication,
kerberos authentication and whatever your server supports without
modifying your application.

 Lukas



On 03/11/2013 03:10 PM, Robert Rothenberg wrote:
> I have a project that requires using HTTP authentication.
> 
> There is a Catalyst::Authentication::Credential::HTTP module, but from the
> documentation, it does not seem to support using htpasswd files, which I
> need, because a separate web site will be using that file.
> 
> There is Catalyst::Authentication::Store::Htpasswd, but it does not work
> with Catalyst::Authentication::Credential::HTTP.
> 
> I'm not clear on how to do this, without having to write my own handlers for
> HTTP authentication.
> 
> 
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Catalyst with HTTP authentication

[Tim Anderson]

Ditto.  I am also using Catalyst::Authentication::Credential::Remote, and
it is working just fine.


-Tim


On Mon, Mar 11, 2013 at 9:37 AM, Lukas Thiemeier
wrote:

> >From reading the docs, I don't see why
> Catalyst::Authentication::Store::Htpasswd and
> Catalyst::Authentication::Credential::HTTP do not work together, but I
> have not used any of them.
>
> I am using Catalyst::Authentication::Credential::Remote in a current
> project. It lets the webserver do all the authentication. You can use
> any authentication method and storage which is supported by your
> webserver, including htpasswd files.
>
> I am using Catalyst::Authentication::Credential::Testing for
> authentication when the webserver is not available (when running the
> catalyst test-server during development).
>
> Maybe this is an option for you...
>
> cheers, Lukas
>
> On 03/11/2013 03:10 PM, Robert Rothenberg wrote:
> > I have a project that requires using HTTP authentication.
> >
> > There is a Catalyst::Authentication::Credential::HTTP module, but from
> the
> > documentation, it does not seem to support using htpasswd files, which I
> > need, because a separate web site will be using that file.
> >
> > There is Catalyst::Authentication::Store::Htpasswd, but it does not work
> > with Catalyst::Authentication::Credential::HTTP.
> >
> > I'm not clear on how to do this, without having to write my own handlers
> for
> > HTTP authentication.
> >
> >
> > ___
> > List: Catalyst@lists.scsys.co.uk
> > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> > Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> > Dev site: http://dev.catalyst.perl.org/
>
>
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Backlog for proposed changes in next Catalyst release

[John Napiorkowski]

>
> From: Bill Moseley 
>To: The elegant MVC web framework  
>Sent: Monday, March 11, 2013 11:48 AM
>Subject: Re: [Catalyst] Backlog for proposed changes in next Catalyst release
> 
>
>
>
>
>On Mon, Mar 11, 2013 at 4:53 AM, Will Crawford  
>wrote:
>
>While it's not Catalyst's fault, I've found over the years that interacting 
>with underlying libraries, databases and legacy systems is generally easier 
>when I *don't* try to force anything. I have custom code in place to deal with 
>know sources of inconsistent encodings (check to see if it's valid UTF8, look 
>up the remainder in a table painstakingly assembled over a period of time that 
>catches a few odd MacRoman characters that show up in some of our 
>contributors' data, fall back to latin1 or cp1252 for the remainder, leave 
>anything else as \xNN). Everywhere else, UTF8 can be passed through quite 
>transparently, so I don't really see the point of adding extra decoding and 
>encoding all over the place to switch from utf8, to some internal wide 
>character encoding, then back to utf8 again for output. One of the positive 
>features of UTF8 has always been that code that doesn't need to identify any 
>of those fancy accented characters can just treat it the same as
 ASCII, Latin-$WHATEVER or cp1252 without any overhead. Overall I can't see the 
point of forcing everything to be converted multiple times ... 
>>
>>
>
>I think we can all agree that historically encoding has been confusing, 
>misunderstood, and frequently ignored.   And very often just done plain wrong.
>

This is exactly the problem. Part of it I think is how some many companies have 
trouble installing stuff from CPAN, so that don't and or don't upgrade very 
much.  Although this is a problem we as a community need to help with, I think 
this is part of why I am pushing to core the obvious stuff into Catalyst, such 
as to make it work more productively and correctly out of the box.

[SNIP]

>
>I have never considered any performance aspect of this.  It never shows up 
>when we profile "slow" responses.  Plus, it's never been an optional 
>operation.   We manipulate characters and we exchange data as bytes.  You have 
>to convert between those.
>
>
>
>
>The plugin should be core to Catalyst.   It think it's pretty safe to add it 
>if it only encodes if the utf8 flag is set on the body -- that should prevent 
>double-encodings.   And having a config option to disable is easy.  And if the 
>plugin is found on the app issue a warning.   It's possible that someone has 
>their own modified version of the plugin using the same name.
>

I think it would be safe to core the behavior but have it off by default for 
the existing legacy project skeleton generator.  No doubt it might cause 
trouble for some people that have hacking Catalyt.pm a lot, but I'm going to go 
out on a limb and suggest if you've hack core you will be able to fix it.  And 
if not, then you shouldn't have hacked it ;)

The 5.9 series will continue to err today backcompat for a while, although 
I would like to lay the groundwork for the features we'd like in Catalyst 6, 
whichi I think we all agree would be allowed to break some backward compat in 
the name of improving the codebase and setting the stage for future 
improvements.  My thinking here is that 5.9xxx would remain hacked on for 
security and bug fixes only, and I really hope that companies that maintain 
that version would step up a bit to help.  At a certain point I think companies 
can't expect volunteers to continue basically working for them for free ;)



>
>
>
>
>
>-- 
>Bill Moseley
>mose...@hank.org 
>___
>List: Catalyst@lists.scsys.co.uk
>Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>Dev site: http://dev.catalyst.perl.org/
>
>
>

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Backlog for proposed changes in next Catalyst release

[Bill Moseley]

On Mon, Mar 11, 2013 at 4:53 AM, Will Crawford
wrote:

> While it's not Catalyst's fault, I've found over the years that
> interacting with underlying libraries, databases and legacy systems is
> generally easier when I *don't* try to force anything. I have custom code
> in place to deal with know sources of inconsistent encodings (check to see
> if it's valid UTF8, look up the remainder in a table painstakingly
> assembled over a period of time that catches a few odd MacRoman characters
> that show up in some of our contributors' data, fall back to latin1 or
> cp1252 for the remainder, leave anything else as \xNN). Everywhere else,
> UTF8 can be passed through quite transparently, so I don't really see the
> point of adding extra decoding and encoding all over the place to switch
> from utf8, to some internal wide character encoding, then back to utf8
> again for output. One of the positive features of UTF8 has always been that
> code that doesn't need to identify any of those fancy accented characters
> can just treat it the same as ASCII, Latin-$WHATEVER or cp1252 without any
> overhead. Overall I can't see the point of forcing everything to be
> converted multiple times ...
>
>
I think we can all agree that historically encoding has been confusing,
misunderstood, and frequently ignored.   And very often just done plain
wrong.

I suspect since this is currently a plugin that it's often ignored,
especially by newer developers.  That means "out of the box" Catalyst, as a
web framework, for its typical use, is broken.


One of the typical uses for a Catalyst application is building a web app
that outputs character data.  This character data must be encoded when sent
over the wire.   Likewise, request data that is character data must be
decoded.  Doing these as close to the "edge" of the application as possible
is the best approach.  That's what the plugin does.

As t0m says, if you are ignoring encoding your app is broken.  Sure, it may
not seem so.  Sure, you can ignore those "fancy accented characters" and if
you app only works in an something like ASCII never notice -- it's just
like before Unicode support was added to Perl.   And you still should set a
charset on the content-type when you send the response, so what are you
going to set it to?

Plus, once you do get some of those fancy characters (used by billions of
people) into your app then all those length() and every other thing that
works with characters (hey, this is Perl) will be broken.


My wild guess from your description above is you are not handling encoding
correctly.  But, in the real world you get character data thrown at you
that is broken in some way.  Perhaps your input is so broken you have to do
what you described.  (Still, I think the correct approach is to decode()
with a useful CHECK value.)   If you are "passing through" UTF8 undecoded
then unless you not touching that input (as character data) then that's
broken.

You say it's best not to force anything, which I assume you mean force as
some encoding.  If you have character input then by nature it's encoded.
 You have to know what the encoding is, and decode it as such and be
prepared for bad data.  You wouldn't ignore it if it was base64 or gzipped,
right?  Those are not character encodings, but it's essentially the same
issue.


I have never considered any performance aspect of this.  It never shows up
when we profile "slow" responses.  Plus, it's never been an optional
operation.   We manipulate characters and we exchange data as bytes.  You
have to convert between those.


The plugin should be core to Catalyst.   It think it's pretty safe to add
it if it only encodes if the utf8 flag is set on the body -- that should
prevent double-encodings.   And having a config option to disable is easy.
 And if the plugin is found on the app issue a warning.   It's possible
that someone has their own modified version of the plugin using the same
name.




-- 
Bill Moseley
mose...@hank.org
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Catalyst with HTTP authentication

[Lukas Thiemeier]

>From reading the docs, I don't see why
Catalyst::Authentication::Store::Htpasswd and
Catalyst::Authentication::Credential::HTTP do not work together, but I
have not used any of them.

I am using Catalyst::Authentication::Credential::Remote in a current
project. It lets the webserver do all the authentication. You can use
any authentication method and storage which is supported by your
webserver, including htpasswd files.

I am using Catalyst::Authentication::Credential::Testing for
authentication when the webserver is not available (when running the
catalyst test-server during development).

Maybe this is an option for you...

cheers, Lukas

On 03/11/2013 03:10 PM, Robert Rothenberg wrote:
> I have a project that requires using HTTP authentication.
> 
> There is a Catalyst::Authentication::Credential::HTTP module, but from the
> documentation, it does not seem to support using htpasswd files, which I
> need, because a separate web site will be using that file.
> 
> There is Catalyst::Authentication::Store::Htpasswd, but it does not work
> with Catalyst::Authentication::Credential::HTTP.
> 
> I'm not clear on how to do this, without having to write my own handlers for
> HTTP authentication.
> 
> 
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Catalyst with HTTP authentication

[Tomas Doran]

On 11 Mar 2013, at 14:10, Robert Rothenberg  wrote:
> There is Catalyst::Authentication::Store::Htpasswd, but it does not work
> with Catalyst::Authentication::Credential::HTTP.

Why? How?

Cheers
t0m


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Catalyst with HTTP authentication

[Robert Rothenberg]

I have a project that requires using HTTP authentication.

There is a Catalyst::Authentication::Credential::HTTP module, but from the
documentation, it does not seem to support using htpasswd files, which I
need, because a separate web site will be using that file.

There is Catalyst::Authentication::Store::Htpasswd, but it does not work
with Catalyst::Authentication::Credential::HTTP.

I'm not clear on how to do this, without having to write my own handlers for
HTTP authentication.


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Backlog for proposed changes in next Catalyst release

[Will Crawford]

On 10 March 2013 19:58, Tomas Doran  wrote:


> Does anyone have a strong opinion on this being added to their app by
> default?
>
> Does anyone have an app which needs you to NOT load the unicode plugin?
> Speak now, or you're gonna have a bad time :)
>

Think I kind of meant to reply to this message just now, not the thread
starter :(
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Backlog for proposed changes in next Catalyst release

[Will Crawford]

While it's not Catalyst's fault, I've found over the years that interacting
with underlying libraries, databases and legacy systems is generally easier
when I *don't* try to force anything. I have custom code in place to deal
with know sources of inconsistent encodings (check to see if it's valid
UTF8, look up the remainder in a table painstakingly assembled over a
period of time that catches a few odd MacRoman characters that show up in
some of our contributors' data, fall back to latin1 or cp1252 for the
remainder, leave anything else as \xNN). Everywhere else, UTF8 can be
passed through quite transparently, so I don't really see the point of
adding extra decoding and encoding all over the place to switch from utf8,
to some internal wide character encoding, then back to utf8 again for
output. One of the positive features of UTF8 has always been that code that
doesn't need to identify any of those fancy accented characters can just
treat it the same as ASCII, Latin-$WHATEVER or cp1252 without any overhead.
Overall I can't see the point of forcing everything to be converted
multiple times ...



On 3 March 2013 16:50, Bill Moseley  wrote:

>
>
> On Fri, Mar 1, 2013 at 9:38 AM, John Napiorkowski wrote:
>
>> Hey All,
>>
>>
>> http://jjnapiorkowski.typepad.com/modern-perl/2013/03/catalyst-backup-for-next-release-on-play-perl.html
>>
>> This is over on play Perl (http://play-perl.org/player/jnap) for your
>> comments and votes.  Hope to see you there!
>>
>
> I think I've asked this before, but is there any talk of native encoding
> support -- meaning make Catalyst::Plugin::Unicode::Encoding part of the
> framework?   Having it a plugin makes it appear as optional, but the
> correct approach is to decoded all text requests and encode all text
> responses.
>
> This is fresh in my mind because last week had problems with two separate
> encoding issues.
>
>
> --
> Bill Moseley
> mose...@hank.org
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
>
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

RE: [Catalyst] C::V::Email and Email::Sender 0.120002 -> 1.300003

[Anthony Gladdish]

Yes this has now fixed it.

Many thanks,
Anthony


From: Dimitar Petrov [mailto:mita...@gmail.com]
Sent: 05 March 2013 15:13
To: The elegant MVC web framework
Subject: Re: [Catalyst] C::V::Email and Email::Sender 0.120002 -> 1.33

Hey Anthony,

reading the changelog of the latest version which is available on CPAN, it 
seems like it's fixed. Here is the Changelog: 
https://metacpan.org/source/DHOSS/Catalyst-View-Email-0.33/Changes

Cheers,
Dimitar

On Tue, Mar 5, 2013 at 4:06 PM, Anthony Gladdish 
mailto:anthony.gladd...@newcastle.ac.uk>> 
wrote:
Hi,

Had this been fixed?

I'm afraid I'm still experiencing the same issue with Email::Sender v1.35 :

Caught exception in MyAppt::View::Email::Template->process "Attribute 
(_mailer_obj) does not pass the type constraint because: Validation failed for 
'Email::Sender::Transport' with value 
Email::Sender::Transport::Test=HASH(0x1eab52e0) at accessor 
Catalyst::View::Email::_mailer_obj
(defined .../Catalyst/View/Email.pm line 21)

Anthony


>-Original Message-
>From: Devin Austin 
>[mailto:devin.aus...@gmail.com]
>Sent: 11 February 2013 15:10
>To: The elegant MVC web framework
>Cc: catalyst@lists.scsys.co.uk
>Subject: Re: [Catalyst] C::V::Email and Email::Sender 0.120002 ->
>1.33
>
>Hi,
>
>I have a patch from Ilmari that fixes this. Among some other
>issues, that will be fixed in this next release which I hope to get
>out today.
>
>On Feb 11, 2013, at 7:44 AM, Anthony Gladdish
>mailto:anthony.gladd...@newcastle.ac.uk>> 
>wrote:
>
>> Hi,
>>
>> Having problems when upgrading from Email::Sender 0.120002
>-> 1.33.
>>
>> While v1.33  compiles and "make test" passes, it appears
>to be no longer working with Catalyst::View::Email ( v0.31 +
>v0.32 ):
>>
>> # 1. Catalyst app config:
>>
>> View::Email::Template:
>>stash_key: 'email'
>>template_prefix: 'email'
>>default:
>>content_type: 'text/plain'
>>charset: 'utf-8'
>>view: 'TT'
>>sender:
>>mailer: Test
>>
>>
>> # 2. some action that sends the email:
>>
>> $c->stash->{email} = {
>>to=>  'blah',
>>from => 'blah',
>>subject => 'blah',
>>template=> 'blah.tt2',
>>};
>>$c->forward( $c->view('Email::Template') );
>>if ( scalar( @{ $c->error } ) ) {
>>$c->error('blah');
>>$c->detach('/end');
>>}
>>
>>
>> # 3. Test:
>>
>> use Test::More;
>> use Email::Sender::Simple;
>>
>> BEGIN {
>>$ENV{EMAIL_SENDER_TRANSPORT} = 'Test';
>> }
>>
>> # some button click that calls action above that sends email <-
>test failing here.
>>
>> my @emails = Email::Sender::Simple->default_transport-
>>deliveries;
>>
>>
>> # Error:
>>
>> Caught exception in MyApp::View::Email::Template->process
>"Attribute (_mailer_obj) does not pass the type constraint
>because: Validation failed for 'Email::Sender::Transport' with
>value Email::Sender::Transport::Test=HASH(0x2b875fe017e0) at
>accessor Catalyst::View::Email::_mailer_obj (defined at ~/
>locallib/lib/perl5/Catalyst/View/Email.pm line 21) line 18.
>>
>> Anyone else getting these sorts of errors?
>> This test script passed before, until upgrading. Is this
>something you can help with?
>>
>> Regards,
>> Anthony
>>
>> ___
>> List: Catalyst@lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-
>bin/mailman/listinfo/catalyst
>> Searchable archive: http://www.mail-
>archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>
>___
>List: Catalyst@lists.scsys.co.uk
>Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>Searchable archive: http://www.mail-
>archive.com/catalyst@lists.scsys.co.uk/
>Dev site: http://dev.catalyst.perl.org/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/