Naveed, I've used both and my take is ... Since Catalyst is meant to be used for large web apps, the scaffolding tool builds a better foundation with good emphasis on MVC, how you should the components and where to place them. Since the latest runs on Plack as does most everything else, there is no real performance difference. In-Short .. the MVC-ness of Catalyst is the only benefit I can think of. I hate when people throw the term "scale" or "web-scale" around ... WTF does that mean? ... its vague enough that it could refer to any number of factors. Most good object-oriented code will "scale" as that its purpose .. other factors such as platform, database, web server, etc (and their respective scalability) have nothing to do with the frameworks scalability.
Send Dancer-users mailing list submissions to
dancer-users@perldancer.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
or, via email, send a message with subject or body 'help' to
dancer-users-request@perldancer.org
You can reach the person managing the list at
dancer-users-owner@perldancer.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dancer-users digest..."
Today's Topics:
1. Re: Questions for Perl Survey (Olaf Alders)
2. Re: Questions for Perl Survey (sawyer x)
3. Catalyst vs Dancer (Naveed Massjouni)
4. Re: Catalyst vs Dancer (Puneet Kishor)
5. Re: CGI/FCGI deployment & uri_for (Robert Olson)
6. flash implementation (???? ??????????)
----------------------------------------------------------------------
Message: 1
Date: Wed, 29 Dec 2010 11:49:53 -0500
From: Olaf Alders <olaf@wundersolutions.com>
Subject: Re: [Dancer-users] Questions for Perl Survey
To: sawyer x <xsawyerx@gmail.com>
Cc: dancer-users@perldancer.org
Message-ID: <5F44E6BE-896E-4D31-9AB4-4CF8275C06D7@wundersolutions.com>
Content-Type: text/plain; charset=us-ascii
On 2010-12-29, at 5:48 AM, sawyer x wrote:
> Dancer provides a thin layer above PSGI and abstraction for some of the work a user would have to do manually (sessions, templating, finding out what type of HTTP method it is, setting the content type, etc.). You (or rather, Dancer, if that's what you're using) provide PSGI with an app handler subroutine. For example:
> sub app {
> my $env = shift;
> return [
> '200',
> [ 'Content-Type' => 'text/plain' ],
> [ "Hello World" ], # or IO::Handle-like object
>
>
> ];
>
> }
> How many people would do that? Very few.
True! However, I'd be interested in seeing how many people are writing their own Plack::Middleware components. As it's a nice and easy way to replace a lot of work you normally might be forced to write with mod_perl handlers, I would expect that the use of custom Middleware should rise over time as well.
Olaf
--
Olaf Alders
olaf@wundersolutions.com
http://www.wundersolutions.com
http://twitter.com/wundercounter
866 503 2204 (Toll free - North America)
416 944 8306 (direct)
------------------------------
Message: 2
Date: Thu, 30 Dec 2010 00:44:44 +0200
From: sawyer x <xsawyerx@gmail.com>
Subject: Re: [Dancer-users] Questions for Perl Survey
To: Olaf Alders <olaf@wundersolutions.com>
Cc: dancer-users@perldancer.org
Message-ID:
<AANLkTime+W5EmthCa6HoS5L47UZF9w_O2AAKrjUzORp6@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Dec 29, 2010 at 6:49 PM, Olaf Alders <olaf@wundersolutions.com>wrote:
>
> [...] I'd be interested in seeing how many people are writing their own
> Plack::Middleware components.
>
Good idea!
> I would expect that the use of custom Middleware should rise over time as
> well.
>
That would be an interesting/useful metric.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20101230/cf45eae4/attachment.html>
------------------------------
Message: 3
Date: Wed, 29 Dec 2010 18:23:21 -0500
From: Naveed Massjouni <naveedm9@gmail.com>
Subject: [Dancer-users] Catalyst vs Dancer
To: dancer-users@perldancer.org
Message-ID:
<AANLkTin9udVMOE1xyvGp54QzTH7wKPTYvmj2LZbPMp0y@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I have a question for all you Dancer users. When would you use
Catalyst over Dancer? Does it "scale" better for larger applications,
and if so how/why? I was never able to wrap my head around Catalyst.
But it's been a while and I was a perl beginner back when I tried.
Now Dancer is my go-to framework for any project. Just wondering if I
am missing out on anything.
Thanks,
Naveed
------------------------------
Message: 4
Date: Wed, 29 Dec 2010 17:51:43 -0600
From: Puneet Kishor <punk.kish@gmail.com>
Subject: Re: [Dancer-users] Catalyst vs Dancer
To: Naveed Massjouni <naveedm9@gmail.com>
Cc: dancer-users@perldancer.org
Message-ID: <4D1BC98F.1040301@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Naveed Massjouni wrote:
> I have a question for all you Dancer users.
I guess you are really asking all "Dancer users who may have also used
Catalyst." I once tried to install Catalyst, but it insisted on
installing a boatload of crap so I gave up.
> When would you use
> Catalyst over Dancer?
Probably never.
Does it "scale" better for larger applications,
> and if so how/why? I was never able to wrap my head around Catalyst.
> But it's been a while and I was a perl beginner back when I tried.
> Now Dancer is my go-to framework for any project. Just wondering if I
> am missing out on anything.
>
I think the better approach might be, is there some specific
functionality that you want that Dancer doesn't provide but Catalyst
does. If yes, it might be worthwhile extending Dancer accordingly. If
not, are both more than one WTDI.
--
Puneet Kishor
------------------------------
Message: 5
Date: Wed, 29 Dec 2010 18:06:45 -0600
From: Robert Olson <bob@rdolson.org>
Subject: Re: [Dancer-users] CGI/FCGI deployment & uri_for
To: Dancer-users@perldancer.org
Message-ID: <A06CD2F6-CB96-40A8-9A5C-49F12897491A@rdolson.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Looking further, I'm seeing various things for doing rewrites of
SCRIPT_NAME for reverse proxies, but not for the rewrite rules of the
form used for the fcgi/cgi deployment.
I'm not sure if this is a good solution or not but plack lets me
define a middleware:
package FixScriptName;
use parent qw(Plack::Middleware);
use strict;
sub call
{
my($self, $env) = @_;
$env->{SCRIPT_NAME} = '';
return $self->app->($env);
}
1;
which I can then enable in config.yml:
plack_middlewares:
-
- +FixScriptName
and uri_for does what I want it to, in this case anyway.
I tried to set up a dancer psgi file to use the Plack Builder DSL to
do configs, but couldn't get it to go right. It seems a little inside
out to define the middleware stack for a dancer app inside the dancer
app configuration. This hack lets me get moving on making my
application do what I want tho.
--bob
On Dec 28, 2010, at 4:53 PM, Robert Olson wrote:
> It seems I must be doing something dumb, but I'm not seeing it.
>
> I'm putting up a dancer app for a domain hosted at dreamhost. I
> created the app using the latest 1.2 dancer, and changed the webroot
> for the domain to appdir/public using the DH config panel. The
> following .htaccess is in place:
>
> AddHandler fastcgi-script .fcgi
> Options +FollowSymLinks +ExecCGI
>
> RewriteEngine On
> RewriteCond %{REQUEST_FILENAME} !-f
> RewriteRule (.*) /dispatch.cgi/$1 [QSA,L]
>
> Access to the routes works like a champ (including
> Net::Google::FederatedLogin authentication which I may turn into a
> plugin; also thinking about a CGI::FormBuilder plugin like
> Catalyst's).
>
> However, uri_for returns a path that includes the rewritten path
> with dispatch.cgi in it:
>
> uri_for("/dog") => http://<domain>/dispatch.cgi/dog
>
> I'm assuming it should instead return http://<domain>/dog.
>
> This seems like something there is an easy solution to, but I'm not
> finding it. Does anyone have any advice?
>
> Thanks,
> --bob
> _______________________________________________
> Dancer-users mailing list
> Dancer-users@perldancer.org
> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
------------------------------
Message: 6
Date: Thu, 30 Dec 2010 10:37:12 +0300
From: ???? ?????????? <ivan@bessarabov.ru>
Subject: [Dancer-users] flash implementation
To: dancer-users <dancer-users@perldancer.org>
Message-ID:
<AANLkTik4uvY2vO-3uyu-QB29PB-8VgeHES2G1vtd8G-w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi!
I've read http://advent.perldancer.org/2010/3 and I have a question.
In the blog implementation, described in the article there is so called "flash".
There is a global variable where one stores some message that is
available after redirect:
my $flash;
sub set_flash { $flash = shift }
sub get_flash { my $msg = $flash; $flash = ""; return $msg } )
post '/add' => sub {
# some lines skipped
set_flash('New entry posted!');
redirect '/';
};
I think there can be a problem with this thing: if there are a lot of
requests to the site some user can see the flash message that was done
for some other user.
Am I right?
I can see several ways of doing the same way but in more safe way:
1. redirect to page with parameter that identifies flash message (have
a problem with not pretty urls)
2. store id to flash message in a cookie
3. store flash message in a session
Any other ways?
------------------------------
_______________________________________________
Dancer-users mailing list
Dancer-users@perldancer.org
http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
End of Dancer-users Digest, Vol 10, Issue 50
********************************************