|
|
[Catalyst-dev] hacking on Session + Session::State::Cookie
By Jonathan Rockway at Sep 22, 2007, 03:12 am UTC
I've been working on these two modules recently. That failing expires test in the cookie dist (that has been giving me nightmares for the last month or so :) is finally passing! However, there is still some weird behavior that I'm noticing. C::P::Continuation only passes its tests if CATALYST_DEBUG... More...
I've been working on these two modules recently. That failing expires
test in the cookie dist (that has been giving me nightmares for the last
month or so :) is finally passing!
However, there is still some weird behavior that I'm noticing.
C::P::Continuation only passes its tests if CATALYST_DEBUG is enabled,
and FormCanary (in git) can only access $c->session->{foo} if I call
$c->session in void context before accessing $c->request and /then/
$c->session->{whatever}. That smells buggy.
I tested some random dists in svn against the new Session code in trunk,
and all of that is passing. random = Store::[FastMmap|DBI],
Catalyst::Plugin::Authentication, and Angerwhale.
Anyway, below is a summary from IRC. I need some sleep before I can
tackle the remaining issues, so just know that there is some potentially
broken/fixed/incomplete/awesomely delicious code in trunk. No action is
required on anyone's part, I just want to let everyone know what's going
on so you don't have to wonder :)
IRC log:
18:57 <@jrockway> ok, i've figured out ::session
18:58 <@jrockway> the problem was that we were sending headers before
updating
the expiry, so it just got ignored
18:58 <@jrockway> that affected the $c->res->body case
18:58 <@jrockway> streaming ($c->res->write) was still broken
18:58 <@jrockway> because that never calls finalize, only finalize_headers
18:58 <@jrockway> so i move the expiry update to finalize_headers
18:58 <@jrockway> and then NEXT::finalize_headers
18:58 <@jrockway> and now everything works again
(editor's note: after i said that, I moved everything but the expiration
update back to finalize. so anything cookie related happens before
sending headers, but everything else happens after the headers and body
have been sent. as a result, that 06finalize test now passes again)
21:19 <@jrockway> catalyst::pluigin::continuation won't pass tests unless
CATALYST_DEBUG=1
21:19 <@jrockway> but, it appears that was the case before i touched
session...
21:22 <@jrockway> ahh, i know
21:22 <@jrockway> recently, calling "$c->session" is required before
$c->session->{whatever} will work
21:22 <@jrockway> i guess that depends on debug/no debug...
21:32 <@jrockway> unrelated
21:32 * jrockway pulls out hair
gnite. sorry this is incoherent :)
Regards,
Jonathan Rockway
Attachment: signature.asc
0 Replies
|
|
|
[Catalyst-dev] What View::Templated does for you :)
By Jonathan Rockway at Sep 20, 2007, 6:45 pm UTC
Now's a good time to discuss the internals of View::Templated so that we can get this thing stable (or deleted) sometime soon :) Here's what sort of fun stuff the View does for the author. render. It looks to see if the user has set a template via $c->view->template('name'), and if he has, returns... More...
Now's a good time to discuss the internals of View::Templated so that
we can get this thing stable (or deleted) sometime soon :)
Here's what sort of fun stuff the View does for the author.
* $view->template is a rw accessor that will always return a template to
render. It looks to see if the user has set a template via
$c->view->template('name'), and if he has, returns that. Next, it looks
for $c->stash->{template} so that it is back-compatible with that
convention. Finally, it returns $c->action concatenated with the
TEMPLATE_EXTENSION. (That's the reason why I initially unified the
configs).
* process works correctly. It determines the charset of the data and
sets the content-type header appropriately (latin-1 data is *NOT* utf-8;
that has caused View::TT users loads-of-pain judging from IRC
conversations and the user list). The content-type defaults to
text/html, but can be changed at new time with the CONTENT_TYPE config
option.
* render works correctly, and better than the version that most people
have cargo-culted. It uses ACCPET_CONTEXT, so you can just say
$view->render('template', { args => ... }). Template and args are both
optional (see the docs for details).
* preprocessing of $c->stash before sending it to the _render method.
$c, $c->req->base, and $c->config->name get turned into "c", "base", and
"name" in the stash passed to the real rendering function (_render),
which then treats them however it treats other keys in the stash. This
is a TT convention, but I wanted it to be the same for any view.
Unfortunately, it doesn't really work for things like Template::Declare
that only know/care about $c. (Mason provides $c, $name, $base... but it
doesn't change $c->stash->{foo} to $foo. So there the system breaks
down :) Thoughts?
Anyway, just wanted to clear this up so I can get some more feedback.
The idea of ::Templated is to make writing an interface to a templating
engine simple for the author and simple to use for the users. As an
author, you don't need to know any details of Catalyst to get your View
to work; ::Templated handles that for you. (I like this approach... do
you?)
The version on CPAN was my first stab, but it is of course open to
changes. Thanks to everyone that has tried it out so far!
Regards,
Jonathan Rockway
0 Replies
|
|
|
[Catalyst-dev] RFC: Catalyst::View::Mason::Templated
By Sebastian Willert at Sep 20, 2007, 6:28 pm UTC
Hi again, I found myself in a Catalyst coding spree lately (or rather in a packaging spree for quite old code) so I present my second request for comments tonight. I use HTML::Mason extensively for most of my projects and was not really satisfied with the amount of features accessible through... More...
Hi again,
I found myself in a Catalyst coding spree lately (or rather in a
packaging spree for quite old code) so I present my second request for
comments tonight. I use HTML::Mason extensively for most of my projects
and was not really satisfied with the amount of features accessible
through Catalyst::View::Mason so I whipped up my own some time ago.
I choose to start virtually from scratch because Catalyst::View::Mason
took some IMO unfortunate design and API decisions early in the modules
lifetime that are really hard to correct without introducing a slew of
backcompat config options (see the INCOMPATIBILITIES section of the
POD). Catalyst::View::Templated came along recently and provided a good
excuse to package and possibly release a Mason view that is based upon
that module.
Here's the POD, so please tell me what you think.
Cheers,
Sebastian
---
NAME
Catalyst::View::Mason::Templated - Full featured Mason View Class
SYNOPSIS
# use the helper
script/create.pl view Mason Mason::Templated
# lib/MyApp/View/Mason.pm
package MyApp::View::Mason;
use base 'Catalyst::View::Mason::Templated';
1;
$c->forward('MyApp::View::Mason');
DESCRIPTION
Want to use a Mason component in your views? No problem!
Catalyst::View::Mason::Templated comes to the rescue.
EXAMPLE
From the Catalyst controller:
$c->stash->{name} = 'Homer'; # Pass a scalar
$c->stash->{extra_info} = {
last_name => 'Simpson',
children => [qw(Bart Lisa Maggie)]
}; # A ref works too
From the Mason template:
<%args>
$name
$extra_info
</%args>
<p>Your name is <strong><% $name %>
<% $extra_info->{last_name} %></strong>
<p>Your children are:
<ul>
% foreach my $child (@{$extra_info->{children}}) {
<li>$child
% }
</ul>
OVERWRITTEN METHODS
new( $c, ?$args )
Parses the mason config and builds a valid "comp_root" out of the
"INCLUDE_PATH" config variable.
ADDITIONAL METHODS
fetch_comp( $template )
Returns an HTML::Mason::Component instance for the given
template path.
Mason templates are compiled to full fledged perl modules with
introspection capabilities and other potential usefull stuff so this
method is provided here even if using it breaks API compatibility with
Catalyst::View::Templated.
MASON CONFIGURATION
This allows you to to pass additional settings to the
HTML::Mason::Interp constructor or to set the options as below:
"DATA_DIR"
Defaults to "File::Spec->tmpdir"
"ALLOW_GLOBALS"
Defaults to "qw/$c $name $base/"
If you add additional allowed globals those will be prepended to the
list of default globals.
Most of the parameters listet in HTML::Mason::Params are also present
(preverably in uppercase), so you can e.g. use your custom request
class.
VIEW CONFIGURATION
"CHARSET"
HTML::Mason isn't bothered with character encodings so you can use
this to set the correct charset for the output string. Setting
"CHARSET" will force a
Enocde::decode( $self->{CHARSET}, [...] )
on the Mason output, thus allowing Catalyst::View::Templated to
guess the correct content-type.
"INCLUDE_PATH"
An array ref containing the user's desired include paths. This is
set to a reasonable default ("root/") if the user omits it from his
config. HTML::Mason forces you to name your include paths if more
than one path is given. If you want to state the path keys
explicitly, it should be of the following form:
MyApp->config->{View::Mason}
= { INCLUDE_PATH =>
[ [ FOO => '/usr/local/foo' ],
[ BAR => '/usr/local/bar' ] ]
};
If no path keys are given, they are calculated from the significant
(i.e. unique) suffix of the path, with the first path always mapped
to "MAIN". This example should give you correct idea:
MyApp->config->{View::Mason}
= { INCLUDE_PATH =>
[ '/usr/local/foo', '/usr/local/foo/widgets',
'/usr/local/bar', '/usr/local/bar/widgets' ],
};
gets transformed to:
MyApp->config->{View::Mason}
= { INCLUDE_PATH =>
[ [ MAIN => '/usr/local/foo' ],
[ FOO_WIDGETS => '/usr/local/foo/widgets' ],
[ BAR => '/usr/local/bar' ],
[ BAR_WIDGETS => '/usr/local/bar/widgets' ] ],
};
Please be aware that you loose compatibility with other
Catalyst::View::Templated classes if you specify the key names.
INCOMPTIBILITIES
CHARSET
The charset of a template no longer defaults to 'utf-8'
CONFIGURATION
Automatic post-processing of Mason config variables is not feed back
into the $self->config hash.
"use_match" will be silently ignored
"template_extension" has been deprecated in favor of
"TEMPLATE_EXTENSION"
EXCEPTION HANDLING
A failed request always dies now, instead of returning false with the
exception in the response body. The error handling is in full
compliance
with Catalyst::View::Templated now.
SEE ALSO
Catalyst, HTML::Mason, "Using Mason from a Standalone Script" in
Catalyst::View::Mason, HTML::Mason::Admin, Catalyst::View::Templated
AUTHOR
Sebastian Willert <willert@cpan.org>
Catalyst::View::Mason::Templated is loosely based on
Catalyst::View::Mason which has been written by the following authors:
Andres Kievsky "ank@cpan.org", Sebastian Riedel "sri@cpan.org", Marcus
Ramberg, Florian Ragwitz <rafl@debian.org>
COPYRIGHT
This program is free software, you can redistribute it and/or modify
it under the same terms as Perl itself.
10 Replies
|
|
|
[Catalyst-dev] RFC: Catalyst::Test::LocalContext
By Sebastian Willert at Sep 19, 2007, 4:15 pm UTC
Hi all, I often found myself wanting to test some internal aspects of my request handling in Catalyst or were to lazy to check the full returned HTML and rather just inspect the stack. For this purpose I expanded Catalyst::Test and threw away its remote functionality. So without further ado, I'd... More...
Hi all,
I often found myself wanting to test some internal aspects of my request
handling in Catalyst or were to lazy to check the full returned HTML and
rather just inspect the stack.
For this purpose I expanded Catalyst::Test and threw away its remote
functionality. So without further ado, I'd like to ask for your comments
on this idea/module/name. POD follows.
Cheers,
Sebastian
---
NAME
Catalyst::Test::LocalContext - Test Catalyst Applications
SYNOPSIS
use Test::More tests => 5;
use Catalyst::Test::LocalContext ’TestApp’;
my $response = request(’/foo’);
isa_ok( $response, q/HTTP::Response/ )
like( get(’/foo’), qr/bar/ );
my $c = prepare(’/foo’);
ok( $c->action->name, ’foo’ )
dispatch( $c );
like( $c->response->body, qr/bar/ );
use HTTP::Request::Common;
$c = dispatch( POST( ’/foo’, [ bar => ’baz’ ] ) );
is( $c->request->method, ’POST’ );
DESCRIPTION
This module tries to provide a test environment for those situations
where Catayst::Test is simply not enough. Basically, it allows you to
test local Catalyst applications and accesses the dispatched context
after the request handling, or create a pristine context object and
manipulate it at your hearts content before dispatching it yourself.
INSTALLED METHODS
All installed methods take either an URI path, a HTTP::Request (e.g.
one produced by HTTP::Request::Common) or a previously prepared
context
object (with the exception of prepare() itself, for obvious reasons).
get
Returns the content.
my $content = get(’foo/bar?test=1’);
Note that this method doesn’t follow redirects, so to test for a
correctly redirecting page you’ll need to use a combination of this
method and the request method below:
my $res = request(’/’); # redirects to /y
warn $res->header(’location’);
use URI;
my $uri = URI->new($res->header(’location’));
is ( $uri->path , ’/y’);
my $content = get($uri->path);
request
Returns the "HTTP::Response" object for this request.
my $res = request(’foo/bar?test=1’);
prepare
Returns a "Catalyst" context object (before dispatching the actual
request). This is especially useful when you like to test internals of
your application or your components.
my $c = prepare(’foo/bar?test=1’);
# do whatever you would do with $c in your actions
ok( $c->request->model, ’GET’ );
dispatch
Returns a "Catalyst" context object (after executing the request) and
the "HTTP::Response" object as an array. You can silently ignore the
response if you are not interested in it and just inspect the context
object.
my $c = dispatch(’foo/bar?test=1’);
my ( $c, $res ) = dispatch(’foo/bar?test=2’);
INTERNAL METHODS
prepare_request
Creates and returns a new context object for a request without
dispatching it. Also returns the HTTP::Request::AsCGI object in list
context.
dispatch_request
Creates a new request object and runs the actual request on it.
Returns the context object (and the response in array context).
SEE ALSO
Catalyst, Catalyst::Test.
AUTHOR
Sebastian Willert <willert@cpan.org>
Heavily based on Catalyst::Test by Sebastian Riedel <sri@cpan.org>
COPYRIGHT
This program is free software, you can redistribute it and/or modify
it under the same terms as Perl itself.
3 Replies
|
|
|
Re: [Catalyst-dev] Ignoring Emacs temp files
By Kieren Diment at Sep 13, 2007, 7:03 pm UTC
Applied (changeset 6741 and 6742 - don't ask) , thanks :-) ... More...
Applied (changeset 6741 and 6742 - don't ask) , thanks :-)
On 27/08/07, Dave Rolsky <autarch@urth.org> wrote:
> When you're editing a buffer in emacs, it will create a temporary symlink
> in the same directory of the file in the form ".#<filename>".
>
> Since these have the same .pm ending as normal modules, Catalyst will
> attempt to load them on startup, and they get included in the watch list
> for the restarting HTTP server. I've attached two patches to tighten up
> the regexes involved so as to avoid this problem.
>
> The first is for Catalyst.pm itself. When using Module::Pluggable::Object,
> it passes a regex to ignore any class name that include ".#", which isn't
> a valid Perl class name anyway (this could be further tightened to really
> only accept valid class names).
>
> The Other is for Catalyst::Devel, and it tweaks the $restart_regex in the
> foo_server.pl script it generates. It basically excludes any path that
> has ".#" at the beginning of the filename or after a slash.
>
>
> -dave
>
> /*===================================================
> VegGuide.Org www.BookIRead.com
> Your guide to all that's veg. My book blog
> ===================================================*/
> _______________________________________________
> Catalyst-dev mailing list
> [email protected: Catalys...@lists.rawmode.org]
> http://lists.rawmode.org/mailman/listinfo/catalyst-dev
>
>
>
_______________________________________________
Catalyst-dev mailing list
[email protected: Catalys...@lists.rawmode.org]
http://lists.rawmode.org/mailman/listinfo/catalyst-dev9 Replies
|
|
|
[Catalyst-dev] Search for catalyst site
By Adam Bartosik at Sep 12, 2007, 7:25 pm UTC
Hi all, I've just added search to catalyst site. I thought about direct "search box" however it is too wide to fit there now and just too work with css. So there is only a link to custom google search with set of catalyst sites. About custom g search: this is connected to google user. Maybe someone... More...
Hi all,
I've just added search to catalyst site. I thought about direct
"search box" however it is too wide to fit there now and just too work
with css. So there is only a link to custom google search with set of
catalyst sites.
About custom g search: this is connected to google user. Maybe someone
of you would like to manage it on its own account /'cause i am new and
no one knows me and i can make stupid things with this bla bla - just
tell me/.
We should be able to customize the layout of the search pages to be
more like catalyst site /see eg.
http://www.googlesyndicatedsearch.com/u/ZHR?hl=en&domains=zhr.pl&ie=ISO-8859-1&q=perl&btnG=Search&sitesearch=zhr.pl
- but now this pure search should just works.
btw - cutted trailing spaces in patch html
7 Replies 
|
|
|
[Catalyst-dev] Re: wtf nosubject worthless spam.
By Evan Carroll at Sep 7, 2007, 2:18 pm UTC
More...
On 9/6/07, [email protected: catalyst-dev-re...@lists.rawmode.org]
<catalyst-dev-request@lists.rawmode.org> wrote:
> Send Catalyst-dev mailing list submissions to
> [email protected: catalys...@lists.rawmode.org]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.rawmode.org/mailman/listinfo/catalyst-dev
> or, via email, send a message with subject or body 'help' to
> [email protected: catalyst-dev-re...@lists.rawmode.org]
>
> You can reach the person managing the list at
> [email protected: catalyst-dev-...@lists.rawmode.org]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Catalyst-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: (no subject) (J. Shirley)
> 2. Re: (no subject) ([email protected: Wade.S...@fallon.com])
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 5 Sep 2007 14:13:09 -0700
> From: "J. Shirley" <jshirley@gmail.com>
> Subject: Re: [Catalyst-dev] (no subject)
> To: "Development of the elegant MVC web framework"
> <catalyst-dev@lists.rawmode.org>
> Message-ID:
> <756703690709051413n55d7bd30ocea275a6d865cdcd@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On 9/5/07, Matt S Trout <dbix-class@trout.me.uk> wrote:
> >
> > On Wed, Sep 05, 2007 at 04:39:52PM -0400, [email protected: razm...@aol.com] wrote:
> > >
> >
> > --
> > Matt S Trout Need help with your Catalyst or DBIx::Class
> > project?
> > Technical Director Want a managed development or deployment
> > platform?
> > Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a
> > quote
> > http://chainsawblues.vox.com/
> > http://www.shadowcat.co.uk/
> >
> > _______________________________________________
> > Catalyst-dev mailing list
> > [email protected: Catalys...@lists.rawmode.org]
> > http://lists.rawmode.org/mailman/listinfo/catalyst-dev
> >
>
>
>
> -- =
>
> J. Shirley :: [email protected: jsh...@gmail.com] :: Killing two stones with one bird...
> http://www.toeat.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.scsys.co.uk/pipermail/catalyst-dev/attachments/20070905/2=
> 44fe006/attachment.html
>
> ------------------------------
>
> Message: 2
> Date: Wed, 5 Sep 2007 16:22:09 -0500
> From: [email protected: Wade.S...@fallon.com]
> Subject: Re: [Catalyst-dev] (no subject)
> To: Development of the elegant MVC web framework
> <catalyst-dev@lists.rawmode.org>
> Cc: "Development of the elegant MVC web framework"
> <catalyst-dev@lists.rawmode.org>
> Message-ID:
> <OF72192801.7BBDD7D9-ON8625734D.00755950-8625734D.007562B4@publicis.com>
>
> Content-Type: text/plain; charset=US-ASCII
>
>
>
>
>
> (no body)
>
> "J. Shirley" <jshirley@gmail.com> wrote on 09/05/2007 04:13:09 PM:
>
> >
>
> > On 9/5/07, Matt S Trout <dbix-class@trout.me.uk> wrote:
> > On Wed, Sep 05, 2007 at 04:39:52PM -0400, [email protected: razm...@aol.com] wrote:
> > >
> >
> > --
> > Matt S Trout Need help with your Catalyst or DBIx::Class
> project?
> > Technical Director Want a managed development or deployment
> platform?
> > Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a
> quote
> > http://chainsawblues.vox.com/
> http://www.shadowcat.co.uk/
> >
> > _______________________________________________
> > Catalyst-dev mailing list
> > [email protected: Catalys...@lists.rawmode.org]
> > http://lists.rawmode.org/mailman/listinfo/catalyst-dev
> >
> >
> >
> > --
> > J. Shirley :: [email protected: jsh...@gmail.com] :: Killing two stones with one bird...
> > http://www.toeat.com _______________________________________________
> > Catalyst-dev mailing list
> > [email protected: Catalys...@lists.rawmode.org]
> > http://lists.rawmode.org/mailman/listinfo/catalyst-dev
>
>
>
>
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Catalyst-dev mailing list
> [email protected: Catalys...@lists.rawmode.org]
> http://lists.rawmode.org/mailman/listinfo/catalyst-dev
>
>
> End of Catalyst-dev Digest, Vol 27, Issue 4
> *******************************************
>
0 Replies
|
|
|
[Catalyst-dev] Make Catalyst::Engine::HTTP run in background easily [Patch + Test]
By Emanuele Zeppieri at Sep 5, 2007, 7:09 pm UTC
This patch simply makes the Catalyst::Engine::HTTP->run() method return the child pid instead of just exit()-ing, when invoked with $options->{background} set. This is IMO quite useful, since it permits to fire a non-blocking external Cat HTTP server simply with something like: my $pid =... More...
This patch simply makes the Catalyst::Engine::HTTP->run() method return
the child pid instead of just exit()-ing, when invoked with
$options->{background} set.
This is IMO quite useful, since it permits to fire a non-blocking
external Cat HTTP server simply with something like:
my $pid = CatApp->run( $PORT, undef, {background => 1} );
# Here go for example tests which connect to the external server...
# ... Then use $pid to kill the server.
which permits to write self-contained test scripts which use an external
Cat HTTP server (which is needed to correctly reproduce an HTTP
transaction).
Please have a look at the attached test: it demonstrates exactly this
kind of use.
This for example permitted to uncover a bug in
Test::WWW::Mechanize::Catalyst which arose *only* when used with an
external server:
http://rt.cpan.org/Ticket/Display.html?id=29143
Cheers,
Emanuele Zeppieri. --- HTTP.pm 2007-09-05 19:40:55.843134100 +0200
+++ HTTP.pm.new 2007-09-05 19:43:19.527134100 +0200
@@ -184,7 +184,7 @@
if ($options->{background}) {
my $child = fork;
die "Can't fork: $!" unless defined($child);
- exit if $child;
+ return $child if $child;
}
my $restart = 0; #!perl
#------------------------------
# Emanuele Zeppieri - Sep 2007
#------------------------------
use strict;
use warnings;
use lib 'lib';
our $PORT;
BEGIN {
$PORT = $ENV{CAT_TEST_PORT} || 7357;
$ENV{CATALYST_SERVER} = "http://localhost:$PORT"
}
package ExternalCatty;
use Catalyst qw/-Debug -Engine=HTTP/;
our $VERSION = '0.01';
__PACKAGE__->config( name => 'ExternalCatty' );
__PACKAGE__->setup;
sub default : Private {
my ($self, $c) = @_;
$c->response->content_type('text/html; charset=utf-8');
$c->response->output( html('Root', 'Hello, test!') )
}
sub html {
my ($title, $body) = @_;
return qq[
<html>
<head>
<title>$title</title>
</head>
<body>$body</body>
</html>
];
}
# Back in main.
package main;
use Test::More tests => 4;
BEGIN {
diag(
"###################################################################\n",
"Starting an external Catalyst HTTP server on port $PORT\n",
"To change the port, please set the CAT_TEST_PORT env variable.\n",
"(The server will be automatically shut-down right after the tests).\n",
"###################################################################\n"
)
}
# Let's catch interrupts to force the END block execution.
$SIG{INT} = sub { warn "INT:$$"; exit };
# Fire an external Catalyst HTTP server without blocking!
my $pid = ExternalCatty->run( $PORT, undef, {background => 1} );
# Test the Cat app through the external server.
use Test::WWW::Mechanize::Catalyst 'ExternalCatty';
my $m = Test::WWW::Mechanize::Catalyst->new;
$m->get_ok('/', 'Get a page from the external server');
is( $m->ct, 'text/html', 'Get the page Content-Type from the external server');
$m->title_is('Root', 'Get page title from the external server');
$m->content_contains(
'Hello, test!',
'get the page body from the external server'
);
END { kill(9, $pid) if defined $pid }
1; _______________________________________________
Catalyst-dev mailing list
[email protected: Catalys...@lists.rawmode.org]
http://lists.rawmode.org/mailman/listinfo/catalyst-dev
1 Reply
|
|
|
[Catalyst-dev] Patches for Catalyst::Plugin::ConfigLoader, Config::All and Config::All::General
By Gareth Kirwan at Aug 22, 2007, 7:33 pm UTC
Matt suggested the sane thing of using "Include config/" in app.conf. I got all excited, wrote my config/{foo,bar,baz}.conf and added it to app.conf. I tested quickly using Config::General as I wrote to make sure I was writing parsable config. I quickly found I needed flags to make it understand... More...
Matt suggested the sane thing of using "Include config/" in app.conf.
I got all excited, wrote my config/{foo,bar,baz}.conf and added it to
app.conf.
I tested quickly using Config::General as I wrote to make sure I was writing
parsable config.
I quickly found I needed flags to make it understand include, dirs, etc.
These flags are not passed by ConfigLoader, and it doesn't have a way to do
so even if it wanted to.
I've patched the necessary files to allow for this, and allowed ->config()
on app to setup the requirements.
Patches and example config are here:
http://scsys.co.uk:8001/8907
6 Replies
|
|
|
[Catalyst-dev] PATCH for Catalyst::Plugin::ConfigLoader
By Greg Sheard at Aug 22, 2007, 7:25 pm UTC
Hi, ConfigLoader seems to use regexps that are too limited in finalize_config. This means that when passing View::TT an INCLUDE_PATH with more than one path specified (such as "__HOME__/template:__HOME__/template2"), only the first __HOME__ is substituted. Attached is a patch to handle this case,... More...
Hi,
ConfigLoader seems to use regexps that are too limited in
finalize_config. This means that when passing View::TT an INCLUDE_PATH
with more than one path specified (such as
"__HOME__/template:__HOME__/template2"), only the first __HOME__ is
substituted. Attached is a patch to handle this case, and the identical
case for using __path_to(some/path)__.
Hope this is okay.
Greg.
--
Greg Sheard <greg.sheard@wcn.co.uk>
Not speaking for WCN plc in any way.
#include "long_disclaimer.h" --- ConfigLoader.pm 2007-08-21 14:14:21.750000000 +0100
+++ ConfigLoader.pm.new 2007-08-21 14:16:51.531250000 +0100
@@ -228,8 +228,8 @@
my $v = Data::Visitor::Callback->new(
plain_value => sub {
return unless defined $_;
- s{__HOME__}{ $c->path_to( '' ) }e;
- s{__path_to\((.+)\)__}{ $c->path_to( split( '/', $1 ) ) }e;
+ s{__HOME__}{ $c->path_to( '' ) }eg;
+ s{__path_to\((.+)\)__}{ $c->path_to( split( '/', $1 ) ) }eg;
}
);
$v->visit( $c->config ); _______________________________________________
Catalyst-dev mailing list
[email protected: Catalys...@lists.rawmode.org]
http://lists.rawmode.org/mailman/listinfo/catalyst-dev6 Replies
|
|
|
[Catalyst-dev] Catalyst::View::ClearSilver broken
By Matt S Trout at Aug 13, 2007, 12:24 pm UTC
You've used $self->config->{foo} to get at config, which breaks configuring the view from MyApp->config and/or a config file. Since you aren't providing your own new() method, you should just __PACKAGE__->mk_ro_accessors(qw(hdfpaths loadpaths template_extension)); and use $self->hdfpaths instead of... More...
You've used $self->config->{foo} to get at config, which breaks configuring
the view from MyApp->config and/or a config file.
Since you aren't providing your own new() method, you should just
__PACKAGE__->mk_ro_accessors(qw(hdfpaths loadpaths template_extension));
and use $self->hdfpaths instead of $self->config->{hdfpaths} etc.
Please can you fix this ASAP, you're the only one with maint on the
View::ClearSilver namespace so now Catalyst's ClearSilver support is broken
and you're the only one who can fix it :)
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director Want a managed development or deployment platform?
Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/
_______________________________________________
Catalyst-dev mailing list
[email protected: Catalys...@lists.rawmode.org]
http://lists.rawmode.org/mailman/listinfo/catalyst-dev0 Replies
|
|
|
[Catalyst-dev] PATCH for Catalyst-Runtime / Catalyst::Utils
By Balint Szilakszi at Aug 9, 2007, 2:18 pm UTC
Hi, Class::Inspector <= 1.16 had a bug where valid module names with segments starting with numbers have been identified as invalid. For example, Quirky::Little::1 or Naught::1024::Bit. Class::Inspector version 1.17 fixes this issue, so I'm attaching this patch that raises the build requirement of... More...
Hi,
Class::Inspector <= 1.16 had a bug where valid module names with
segments starting with numbers have been identified as invalid.
For example, Quirky::Little::1 or Naught::1024::Bit.
Class::Inspector version 1.17 fixes this issue, so I'm attaching this
patch that raises the build requirement of Class::Inspector from 1.06 to
1.17 in Makefile.PL.
In addition to this, the patch adds a test that checks whether modules
with numbers can be loaded correctly. I've also made the Catalyst::Utils
code a bit more precise to distinguish between the conditions when
Class::Inspector returns undef, which means that it thinks the passed
package name is invalid, and when it returns a defined value which
evaluates to false, which means that Class::Inspector doesn't think the
package with the given name has been loaded. Index: t/unit_utils_load_class.t
===================================================================
--- t/unit_utils_load_class.t (revision 6624)
+++ t/unit_utils_load_class.t (working copy)
@@ -3,7 +3,7 @@
use strict;
use warnings;
-use Test::More tests => 12;
+use Test::More tests => 14;
use lib "t/lib";
@@ -13,12 +13,18 @@
package This::Module::Is::Not::In::Inc::But::Does::Exist;
sub moose {};
}
+{
+ package This::Module::Has::1::Or::2::Numbers;
+ sub moose {};
+}
my $warnings = 0;
$SIG{__WARN__} = sub { $warnings++ };
ok( !Class::Inspector->loaded("TestApp::View::Dump"), "component not yet loaded" );
+ok( !defined(Class::Inspector->loaded("1::Faulty::Module::Name")), "returns undef to signal error correctly" );
+
Catalyst::Utils::ensure_class_loaded("TestApp::View::Dump");
ok( Class::Inspector->loaded("TestApp::View::Dump"), "loaded ok" );
@@ -49,3 +55,6 @@
eval { Catalyst::Utils::ensure_class_loaded("This::Module::Is::Not::In::Inc::But::Does::Exist") };
ok( !$@, "no error when loading non existent .pm that *does* have a symbol table entry" );
+undef $@;
+eval { Catalyst::Utils::ensure_class_loaded("This::Module::Has::1::Or::2::Numbers") };
+ok( !$@, "no error when loading modules when a segment of their name begins with a number" );
Index: lib/Catalyst/Utils.pm
===================================================================
--- lib/Catalyst/Utils.pm (revision 6624)
+++ lib/Catalyst/Utils.pm (working copy)
@@ -258,8 +258,12 @@
}
die $error if $error;
- die "require $class was successful but the package is not defined"
- unless Class::Inspector->loaded($class);
+ my $status = Class::Inspector->loaded($class);
+ if (!defined($status)) {
+ die "require $class was successful but Class::Inspector thinks the class name is invalid";
+ } elsif (!$status) {
+ die "require $class was successful but the package is not defined";
+ }
return 1;
}
Index: Makefile.PL
===================================================================
--- Makefile.PL (revision 6624)
+++ Makefile.PL (working copy)
@@ -9,7 +9,7 @@
requires 'Carp';
requires 'Class::Accessor::Fast';
requires 'Class::Data::Inheritable';
-requires 'Class::Inspector' => '1.06';
+requires 'Class::Inspector' => '1.17';
requires 'CGI::Simple::Cookie';
requires 'Data::Dump';
requires 'File::Modified'; _______________________________________________
Catalyst-dev mailing list
[email protected: Catalys...@lists.rawmode.org]
http://lists.rawmode.org/mailman/listinfo/catalyst-dev
3 Replies
|
|
|
[Catalyst] Canonical address changes from rawmode.org -> scsys.co.uk
By Matt S Trout at Aug 8, 2007, 7:09 pm UTC
I'm sick of having to interrupt gabb in .cz every time the list server moves IP so I'm centralising stuff under an SC domain. The lists.scsys.co.uk URLs and mail acceptors -should- already work and I'm not going to turn lists.rawmode.org off just yet but people seem to have missed the announce on... More...
I'm sick of having to interrupt gabb in .cz every time the list server moves
IP so I'm centralising stuff under an SC domain.
The lists.scsys.co.uk URLs and mail acceptors -should- already work and I'm
not going to turn lists.rawmode.org off just yet but people seem to have
missed the announce on the DBIC list and keep complaining their sieve
configs don't work, so can you all get this done -now- and I'll cut it over
later please :)
Also, somebody get the cat docs changed and a new manual release ready.
1 Reply
|
|
|
[Catalyst-dev] tasks for 5.80?
By John Napiorkowski at Aug 7, 2007, 2:40 pm UTC
Hi, If there are any people working on outstanding issues for the next catalyst release and would like some help, particularly with lighter weight tasks such as as writing test cases, etc. please let me know. I'm probably not the sharpest knife in the drawer, but if I have a clear task a a little... More...
Hi,
If there are any people working on outstanding issues
for the next catalyst release and would like some
help, particularly with lighter weight tasks such as
as writing test cases, etc. please let me know.
I'm probably not the sharpest knife in the drawer, but
if I have a clear task a a little suggestions I am
sure I can help.
Sorry, I can only access IRC sporadically, so I don't
know what conversations and/or tasks have been laid
out.
Thanks!
--John
____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
http://farechase.yahoo.com/
0 Replies
|
|
|
[Catalyst-dev] OT: Re: branch cleanup
By Carl Franks at Aug 6, 2007, 2:56 pm UTC
Sorry - I tagged this mail, but never got round to replying. There's been a few dev releases of HTML::FormFu to CPAN - but none in the past month, mostly because I was on holiday for most of July. We've a few dozen subscribers on the mailing list, and a handful of active contributors. There's a few... More...
On 18/06/07, A. Pagaltzis <pagaltzis@gmx.de> wrote:
> * Carl Franks <fireartist@gmail.com> [2007-06-18 11:30]:
> > On 18/06/07, Jonathan Rockway <jon@jrock.us> wrote:
> > >HTML-Widget-fireartist (old?)
> >
> > ...was a refactor that was abandoned in favour of developing
> > HTML-FormFu. please delete.
>
> How's that coming along anyway? It's getting kinda long in the
> tooth (though you have quite a ways before you approach TT3).
Sorry - I tagged this mail, but never got round to replying.
There's been a few dev releases of HTML::FormFu to CPAN - but none in
the past month, mostly because I was on holiday for most of July.
We've a few dozen subscribers on the mailing list, and a handful of
active contributors.
There's a few features I'd like to add before making a public release
- but other than that, it's fairly stable.
Carl
0 Replies
|
|
|
[Catalyst-dev] Re: Re: PATCH: refactor Catalyst::Engine::HTTP::Restarter to standalone module
By Mark Stosberg at Aug 3, 2007, 3:38 pm UTC
I continued to look at this issue tonight, and came up with a patch for HTTP::Server::Simple that uses simple signal handling. Unless there is a reason to allow restarting of the web server from remote machines (!!), switching to this kind of signal handling system does seem like a good solution.... More...
Matt S Trout wrote:
> On Sun, Jul 22, 2007 at 04:30:48PM -0400, Mark Stosberg wrote:
>> Matt S Trout wrote:
>>
>> > On Sun, Jul 22, 2007 at 08:58:42AM -0400, Mark Stosberg wrote:
>> >> Hello,
>> >>
>> >> I like the auto-restart feature that is in the Catalyst
>> >> HTTP::Restarter server. I wanted to use the restarting trick with a
>> >> project based on HTTP::Server::Simple, so I looked to see how tied
>> >> this functionality was to Catalyst. Here's what I found:
>> >>
>> >> Catalyst::Engine::HTTP::Restarter::Watcher is not functionally tied to
>> >> Catalyst at all. It just shares a namespace.
>> >>
>> >> Catalyst::Engine::HTTP::Restarter depends on no functionality from
>> >> Catalyst but was still coupled with it through a base-class
>> >> relationship which could be easily avoided.
>> >>
>> >> The attached patch moves these to modules into the
>> >> HTTP::Server::Restarter namespace, and makes slight alternations to
>> >> the other Catalyst files so that the functionality remains the same,
>> >> as well as the dependencies.
>> >
>> > Wouldn't Devel::Restart::Automatic or similar be more sensible
>> > name-wise?
>> >
>> > I don't see that there needs to be anything HTTP-dependent in the code
>> > you're factoring out.
>>
>> The approach is HTTP specific. The monitor acts as HTTP client and sends
>> a special "RESTART" requeest over HTTP when a change is detected. I
>> looked at two different approaches today that involved sending a SIGHUP
>> signal instead, and I couldn't get either to work. I suspect the authors
>> settled on this approach because it was reliable by comparison.
>
> I suspect SIGUSR1 would work just fine; the 'authors' (mostly Sebastian)
> don't actually understand signal handling, I had to do quite a lot of
> cleanup work to make the child-related stuff sane.
I continued to look at this issue tonight, and came up with a patch for
HTTP::Server::Simple that uses simple signal handling. Unless there is a
reason to allow restarting of the web server from remote machines (!!),
switching to this kind of signal handling system does seem like a good
solution.
http://rt.cpan.org/Ticket/Display.html?id=28423#txn-347392
>> So, I think HTTP::Server::Restarter is good that part. The second
>> module, "Watcher.pm" is not HTTP-specific, it just monitors a directory
>> for
>> changes, based some options. It is similar to: "File::Monitor".
>>
>> http://search.cpan.org/~andya/File-Monitor-v0.0.5/
>>
>> I suggest it be named "File::Monitor::Simple"
>
> Is there any reason not to switch to File::Monitor while we're here?
Yes, File::Monitor is much larger than you need. The current Catalyst
solution does leverage some existing files:
use File::Find;
use File::Modified;
use File::Spec;
Catalyst has a nice small, simple alternative to File::Monitor. Maybe it's
File::Monitor::Tiny. :)
> Please try and subscribe again, and contact me at the provided address if
> you continue to have problems.
I was able to subscribe this time around, and this has been moved to
the -dev list now.
Mark
4 Replies
|
|
|
[Catalyst-dev] Re: jshirley/jrockway
By Evan Carroll at Jul 30, 2007, 04:46 am UTC
Because Email::Send does not take an Array of HashRefs it just takes an Array. And this is a wrapper around Email::Send and pod and code says these are ->{mailer_args} Good enough for me. I didn't know it was using localhost, only that it was neither dieing nor was traffic going out eth1. So it... More...
> Message: 2
> Date: Fri, 27 Jul 2007 18:27:30 -0500
> From: "Jonathan T. Rockway" <jon@jrock.us>
> Subject: Re: [Catalyst-dev] Catalyst::View::Email patch courtesy of
> the one and only.
> To: Development of the elegant MVC web framework
> <catalyst-dev@lists.rawmode.org>
> Message-ID: <20070727232730.GA32243@jrock.us>
> Content-Type: text/plain; charset=us-ascii
>
> On Fri, Jul 27, 2007 at 05:06:38PM -0500, Evan Carroll wrote:
> > --- a/Email.pm
> > +++ b/Email.pm
> > @@ -35,9 +35,12 @@ In your app configuration (example in L<YAML>):
> > method: SMTP
> > # mailer_args is passed directly into Email::Send
> > mailer_args:
> > - - Host: smtp.example.com
> > - - username: username
> > - - password: password
> > + - Host
> > + - smtp.example.com
> > + - username
> > + - mySMPTUsername
> > + - password
> > + - mySMTPPassword
>
> Why are you doing this?
Because Email::Send does not take an Array of HashRefs it just takes
an Array. And this is a wrapper around Email::Send and pod and code
says these are ->{mailer_args}
>
> Regards,
> Jonathan Rockway
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 27 Jul 2007 20:38:35 -0700
> From: "J. Shirley" <jshirley@gmail.com>
> Subject: Re: [Catalyst-dev] Catalyst::View::Email patch courtesy of
> the one and only.
> To: "Development of the elegant MVC web framework"
> <catalyst-dev@lists.rawmode.org>
> Message-ID:
> <756703690707272038j263cca32j8c8500adbf4919e2@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 7/27/07, Evan Carroll <lists@evancarroll.com> wrote:
> > added verbosity to error to reflect nested args ie AoH throwing off error check
> >
> > fixed typo in docs, mailer_args is supposed to be an array not a hash,
> > now yaml shows it.
> >
> > removed old * for ->sender->{mailer_args}
> > we now support the documented fashion!! but we carp - because it isn't
> > supported by Email::Send ie we now coerce into ArrayRef is HashRef is
> > supplied.
> >
> > We also croak if neither HashRef nor ArrayRef is supplied
> >
> > We now check that Host is supplied if the ->mailer is SMTP
> >
> >
> > diff --git a/Email.pm b/Email.pm
> > index e4be27c..b422e54 100644
> > --- a/Email.pm
> > +++ b/Email.pm
> > @@ -35,9 +35,12 @@ In your app configuration (example in L<YAML>):
> > method: SMTP
> > # mailer_args is passed directly into Email::Send
> > mailer_args:
> > - - Host: smtp.example.com
> > - - username: username
> > - - password: password
> > + - Host
> > + - smtp.example.com
> > + - username
> > + - mySMPTUsername
> > + - password
> > + - mySMTPPassword
> >
> > =cut
> >
> > @@ -110,24 +113,64 @@ Then, Catalyst::View::Email will forward to your
> > View::TT by default.
> >
> > sub new {
> > my $self = shift->next::method(@_);
> > -
> > my ( $c, $arguments ) = @_;
> >
> > my $mailer = Email::Send->new;
> >
> > - if ( my $method = $self->sender->{method} ) {
> > - croak "$method is not supported, see Email::Send"
> > - unless $mailer->mailer_available($method);
> > - $mailer->mailer($method);
> > - } else {
> > - # Default case, run through the most likely options first.
> > - for ( qw/SMTP Sendmail Qmail/ ) {
> > - $mailer->mailer($_) and last if $mailer->mailer_available($_);
> > + my $chosen_method;
> > +
> > + ##
> > + ## If mailer is provided - check to make sure it is avail.
> > + ##
> > + if ( $chosen_method = $self->sender->{method} ) {
> > + croak "$chosen_method is not supported, see Email::Send"
> > + unless $mailer->mailer_available($chosen_method)
> > + ;
> > + $mailer->mailer($chosen_method);
> > + }
> > +
> > + ##
> > + ## Default case, run through the most likely options first.
> > + ##
> > + else {
> > + for my $default_method ( qw/SMTP Sendmail Qmail/ ) {
> > + if ( $mailer->available($default_method) ) {
> > + $mailer->mailer($default_method);
> > + carp "Warning making assumption that $default_method is
> > the desired method";
> > + last;
> > + }
> > }
> > }
> >
> > - if ( $self->sender->{mailer_args} ) {
> > - $mailer->mailer_args($self->sender->{mailer_args});
> > + ##
> > + ## Runtime checks to make sure that an Array is provided if anything
> > + ##
> > + my $mailer_args = $self->sender->{mailer_args};
> > + if ( $mailer_args ) {
> > +
> > + if ( ref $mailer_args eq 'HASH' ) {
> > + carp 'Attempting to coerce HashRef ->{mailer_args} '
> > + . 'into Email::Send required ArrayRef'
> > + ;
> > + $mailer_args = [%{$mailer_args}];
> > + }
> > + elsif ( ref $mailer_args ne 'ARRAY' ) {
> > + croak 'Please send something non-retarded for ->sender->{mailer_args}';
> > + }
> > +
> > + ##
> > + ## Further checks here against thine ->{mailer_args}
> > + ## Total bull shit Email::Send does not croak without this
> > + ##
> > + my %hash_args = ( @$mailer_args );
> > + croak 'No ->{Host} provided with method SMTP, '
> > + . 'check to make sure data structure sent to ->{mailer_args}
> > is not nested'
> > + if $chosen_method eq 'SMTP'
> > + && !defined $hash_args{Host}
> > + ;
> > +
> > + $mailer->mailer_args( $mailer_args );
> > +
> > }
> >
> > $self->mailer($mailer);
> >
> >
> >
> > I am awesome.
> >
>
> Your style changes are not going to be accepted.
>
> Adding in the type check on mailer_args is a good idea, and is implemented.
>
> The croak on Host not being specified is just plain dumb. That
> doesn't belong here, that belongs in Email::Send::SMTP, and they
> default to 'localhost'. This is pretty common (although undocumented)
> behavior. I'd recommend you file a ticket against Email::Send::SMTP
> asking them to document or change behavior to suit your desires.
>
> I'm not going to change their behavior, since I do specifically state
> that Catalyst::View::Email is a gateway to Email::Send. I will,
> however, point it out in the Pod.
Good enough for me. I didn't know it was using localhost, only that it
was neither dieing nor was traffic going out eth1. So it appeared to
just be silently failing. I'd still keep the part there about
$chosen_method and make it accessible...
And update the POD to reflect an Array rather than an AoH
>
> -Jay
>
> --
> J. Shirley :: [email protected: jsh...@gmail.com] :: Killing two stones with one bird...
> http://www.toeat.com
>
--
Evan Carroll
System Lord of the Internets
[email protected: m...@evancarroll.com]
832-445-8877
_______________________________________________
Catalyst-dev mailing list
[email protected: Catalys...@lists.rawmode.org]
http://lists.rawmode.org/mailman/listinfo/catalyst-dev4 Replies
|
|
|
[Catalyst-dev] Catalyst::View::Email patch courtesy of the one and only.
By Evan Carroll at Jul 28, 2007, 03:38 am UTC
added verbosity to error to reflect nested args ie AoH throwing off error check fixed typo in docs, mailer_args is supposed to be an array not a hash, now yaml shows it. removed old * for ->sender->{mailer_args} we now support the documented fashion!! but we carp - because it isn't supported by... More...
added verbosity to error to reflect nested args ie AoH throwing off error check
fixed typo in docs, mailer_args is supposed to be an array not a hash,
now yaml shows it.
removed old * for ->sender->{mailer_args}
we now support the documented fashion!! but we carp - because it isn't
supported by Email::Send ie we now coerce into ArrayRef is HashRef is
supplied.
We also croak if neither HashRef nor ArrayRef is supplied
We now check that Host is supplied if the ->mailer is SMTP
diff --git a/Email.pm b/Email.pm
index e4be27c..b422e54 100644
--- a/Email.pm
+++ b/Email.pm
@@ -35,9 +35,12 @@ In your app configuration (example in L<YAML>):
method: SMTP
# mailer_args is passed directly into Email::Send
mailer_args:
- - Host: smtp.example.com
- - username: username
- - password: password
+ - Host
+ - smtp.example.com
+ - username
+ - mySMPTUsername
+ - password
+ - mySMTPPassword
=cut
@@ -110,24 +113,64 @@ Then, Catalyst::View::Email will forward to your
View::TT by default.
sub new {
my $self = shift->next::method(@_);
-
my ( $c, $arguments ) = @_;
my $mailer = Email::Send->new;
- if ( my $method = $self->sender->{method} ) {
- croak "$method is not supported, see Email::Send"
- unless $mailer->mailer_available($method);
- $mailer->mailer($method);
- } else {
- # Default case, run through the most likely options first.
- for ( qw/SMTP Sendmail Qmail/ ) {
- $mailer->mailer($_) and last if $mailer->mailer_available($_);
+ my $chosen_method;
+
+ ##
+ ## If mailer is provided - check to make sure it is avail.
+ ##
+ if ( $chosen_method = $self->sender->{method} ) {
+ croak "$chosen_method is not supported, see Email::Send"
+ unless $mailer->mailer_available($chosen_method)
+ ;
+ $mailer->mailer($chosen_method);
+ }
+
+ ##
+ ## Default case, run through the most likely options first.
+ ##
+ else {
+ for my $default_method ( qw/SMTP Sendmail Qmail/ ) {
+ if ( $mailer->available($default_method) ) {
+ $mailer->mailer($default_method);
+ carp "Warning making assumption that $default_method is
the desired method";
+ last;
+ }
}
}
- if ( $self->sender->{mailer_args} ) {
- $mailer->mailer_args($self->sender->{mailer_args});
+ ##
+ ## Runtime checks to make sure that an Array is provided if anything
+ ##
+ my $mailer_args = $self->sender->{mailer_args};
+ if ( $mailer_args ) {
+
+ if ( ref $mailer_args eq 'HASH' ) {
+ carp 'Attempting to coerce HashRef ->{mailer_args} '
+ . 'into Email::Send required ArrayRef'
+ ;
+ $mailer_args = [%{$mailer_args}];
+ }
+ elsif ( ref $mailer_args ne 'ARRAY' ) {
+ croak 'Please send something non-retarded for ->sender->{mailer_args}';
+ }
+
+ ##
+ ## Further checks here against thine ->{mailer_args}
+ ## Total bull shit Email::Send does not croak without this
+ ##
+ my %hash_args = ( @$mailer_args );
+ croak 'No ->{Host} provided with method SMTP, '
+ . 'check to make sure data structure sent to ->{mailer_args}
is not nested'
+ if $chosen_method eq 'SMTP'
+ && !defined $hash_args{Host}
+ ;
+
+ $mailer->mailer_args( $mailer_args );
+
}
$self->mailer($mailer);
I am awesome.
2 Replies
|
|
 | |
