Re: Recommendation for simple Web Frameworks
David == David Cantrell da...@cantrell.org.uk writes: David nor do I particularly relish having a seperate build of perl David with its own @INC sandbox for every application. David Yes, it is, and I do that. However, you appear to have not David read the bit where I said a seperate build of perl with its David own @INC sandbox for every application. Let me clear that up for you: It's pretty trivial to build and load perl modules somewhere other than the vendor perl lib directories where they might risk breaking the system ... without having a separate perl build with it's own @INC sandbox. Everyone does have every right to arbitrarily not relish that approach (and then go ahead and do it anyway). David Were you born that stupid, or did you have to work at it? Also hardly the topic, if you had an actual argument, I'd be glad to dicusss it. Sad to see an otherwise interesting technical discussion degenerate ad hominem. I apologise to the other readers that it happened on a subject I was involved in. -- Eden Cardim Software Engineer Shadowcat Systems Ltd. http://www.shadowcat.co.uk http://blog.edencardim.com
Re: Recommendation for simple Web Frameworks
On Thu, Jan 13, 2011 at 12:54:38PM -0200, Eden Cardim wrote: David == David Cantrell da...@cantrell.org.uk writes: David nor do I particularly relish having a seperate build of perl David with its own @INC sandbox for every application. Everyone does have every right to arbitrarily not relish that approach (and then go ahead and do it anyway). The point is that something with fewer dependencies, and hence less risk of breaking other stuff, makes it less necessary. What about this do you find so hard to understand? -- David Cantrell | top google result for internet beard fetish club Every normal man must be tempted at times to spit on his hands, hoist the black flag, and begin slitting throats. -- H. L. Mencken
Re: Recommendation for simple Web Frameworks
On 10 Jan 2011 22:06, John Imison i...@moe.co.uk wrote: Out of interest, does anyone use CGI::Application? What are the general thoughts on that? I've used in past roles, as a relatively simple dispatcher for web services. Anything more involved than that, and it becomes a but of a pain, not for the core system. Rather due to some plugins for it changing the dispatch or exception handling needlessly. When using multiple plugins, this becomes a maintenance headache. That being said, it's been a couple of years since I last used, so that situation may have changed. Mark.
Re: Recommendation for simple Web Frameworks
On 12/01/2011, at 7:26 PM, Mark Morgan wrote: That being said, it's been a couple of years since I last used, so that situation may have changed. Apparently not: Gabor Szabo szabgab at gmail.com wrote: I have been using CGI::Applications for many years. IMHO the biggest problem with it is its name[1]. AFAIK it the development is not that active because the developers 1) do not want it to be a big framework like Catalyst 2) find that it has been mature for several years now Even though I do [hear] things happening on the mailing list here and there. I am now playing with Dancer because it is a new toy and it has a cooler name than CGI::Application.
Re: Recommendation for simple Web Frameworks
On Tue, Jan 11, 2011 at 05:12:55PM -0200, Eden Cardim wrote: David == David Cantrell da...@cantrell.org.uk writes: David You don't have to be in a corporate environment for that to David be a pain in the arse. On my own machines I don't really David want to run the risk that one of those 70+ dependencies will David break something else, nor do I particularly relish having a David seperate build of perl with its own @INC sandbox for every David application. It's pretty trivial to build and load perl modules somewhere other than the vendor perl lib directories where they might risk breaking the system. Yes, it is, and I do that. However, you appear to have not read the bit where I said a seperate build of perl with its own @INC sandbox for every application. The only real reason you have to stay away from dependencies in a corporate environment is when it's enforced legally Were you born that stupid, or did you have to work at it? -- David Cantrell | Godless Liberal Elitist There are many different types of sausages. The best are from the north of England. The wurst are from Germany. -- seen in alt.2eggs...
Re: Recommendation for simple Web Frameworks
On 10/01/2011 10:29 PM, Dave Hodgkinson wrote: Out of interest, does anyone use CGI::Application? What are the general thoughts on that? As a dispatcher, it's fine. DBIC+TT+CGI::App is a framework :) Great. I'm glad to hear that some people on here are using it. I've been using DBIC+TT+CGI::App for a little while and found the learning curve to be small/fast and wanted to knock something up quickly. Most perl irc channels were recommending Catalyst, Dancer and Mojolicious as the main frameworks and I was worried that there may have been something wrong with CGI::App that I didn't know about. I guess the main difference is the 3 above are actively being developed? Thanks. Regards, John
Re: Recommendation for simple Web Frameworks
On Tue, Jan 11, 2011 at 10:10 AM, John Imison i...@moe.co.uk wrote: On 10/01/2011 10:29 PM, Dave Hodgkinson wrote: Out of interest, does anyone use CGI::Application? What are the general thoughts on that? As a dispatcher, it's fine. DBIC+TT+CGI::App is a framework :) Great. I'm glad to hear that some people on here are using it. I've been using DBIC+TT+CGI::App for a little while and found the learning curve to be small/fast and wanted to knock something up quickly. Most perl irc channels were recommending Catalyst, Dancer and Mojolicious as the main frameworks and I was worried that there may have been something wrong with CGI::App that I didn't know about. I guess the main difference is the 3 above are actively being developed? I have been using CGI::Applications for many years. IMHO the biggest problem with it is its name[1]. AFAIK it the development is not that active because the developers 1) do not want it to be a big framework like Catalyst 2) find that it has been mature for several years now Even though I do things happening on the mailing list here and there. I am now playing with Dancer because it is a new toy and it has a cooler name than CGI::Applications. regards Gabor http://szabgab.com/ [1] That was part of the reason for the repackaging as Titanium
Re: Recommendation for simple Web Frameworks
On Tue, Jan 11, 2011 at 9:26 AM, Gabor Szabo szab...@gmail.com wrote: On Tue, Jan 11, 2011 at 10:10 AM, John Imison i...@moe.co.uk wrote: On 10/01/2011 10:29 PM, Dave Hodgkinson wrote: Out of interest, does anyone use CGI::Application? What are the general thoughts on that? As a dispatcher, it's fine. DBIC+TT+CGI::App is a framework :) Great. I'm glad to hear that some people on here are using it. I've been using DBIC+TT+CGI::App for a little while and found the learning curve to be small/fast and wanted to knock something up quickly. Most perl irc channels were recommending Catalyst, Dancer and Mojolicious as the main frameworks and I was worried that there may have been something wrong with CGI::App that I didn't know about. I guess the main difference is the 3 above are actively being developed? I have been using CGI::Applications for many years. IMHO the biggest problem with it is its name[1]. AFAIK it the development is not that active because the developers 1) do not want it to be a big framework like Catalyst 2) find that it has been mature for several years now Even though I do things happening on the mailing list here and there. In my opinion the nice thing when switching from CGI::Application to Catalyst was that the application naturally was split into multiple classes - while CGI::Application, out of the box, is just one package. At work we had a CGI::Application that was one package split into multiple files because it was so big. That was a nightmare. I am sure there was a better way to do that - but this is how things grow organically. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/
Re: Recommendation for simple Web Frameworks
Simon == Simon Wistow si...@thegestalt.org writes: Simon You can see how I'd be confused given that the docs say Simon Catalyst follows the Model-View-Controller (MVC) design pattern, Simon allowing you to easily separate concerns, like content, presentation, Simon and flow control, into separate modules. Simon Now true that doesn't necessarily preclude me from not creating models Simon but it does seem to imply that they are somewhat expected. The documentation is written that way because it's what newcomers expect from a framework, but it does say allowing (not expecting). The implementation doesn't force you to follow the MVC paradigm at all, it's much like perl in the sense that it has OO support but it doesn't force you to follow the paradigm. What might be missing is a how to write non-mvc applications catalyst document. Simon My experience with most of the major web frameworks across 3 Simon different languages has indicated that much of their utility is based on Simon the automagic they provide. Magic requires a fair bit of Simon convention-over-configuration or, at least, expects you to be doing Simon things The Right Way[tm] and attempts to circumvent tend to lead to Simon problems. That's the case with most of the major frameworks yes, but not the case with catalyst, it's more like heavy configuration, sane defaults, you don't even need the scaffold structure that the helpers build and you can even re-wire the entire dispatcher via configuration without ever touching application code.Again, the scaffolding is there because newcomers need a sense of structure to follow. Simon And I'm fine with that - it's a good thing and for 90% of people it's Simon probably the right thing. Simon However I didn't want to be in the position where, somewhere down the Simon line, I started having to wrap hashes in fake pseudo-Catalyst::Model Simon classes in order to get stuff working with some component or plugin Simon because the author of that (quite rightly) assumed that no fool would Simon ever not be using models. [*] You don't have to wrap anything in a pseudo-model-class, you'll notice that the demo app built by the scaffolder works and it has no views/models. Your app could be one big subroutine if you wanted to, but then you wouldn't need catalyst, you'd be better off with a PSGI app. Simon I may have the wrong impression but my experience with a large Catalyst Simon app (TypePad) and reading the docs lead me to that Simon impression. You wouldn't be the only one, makes me think there's a mistake in how the framework is advertised. I've done several large apps in catalyst, some were good, some were ok, some were bad, no silver bullet. Simon Other reasons for not going with Catalyst which may or may not be FUD: Simon * Felt too heavy. I needed a very simple app and Catalyst seems Simon designed for non-simple apps. This might be FUD, I'm not sure I understand what too heavy means, I guess it means you don't need the robustness and flexibility. If that's the case, you have a valid point here, there's no reason to use catalyst at all. Simon * Bad experience with Catalyst based app start up times during Simon development cycles (this is also true for Django and Rails FWIW) Valid point, it's optimized for runtime in expense of load time. And it did outperform both django and rails the last time I checked. Simon * Too many dependencies I disagree that this is a disadvantage but that's for another discussion. Simon * Moose. I just don't like it - but that's just me. Fair point. Simon Don't get me wrong, I think Catalyst is great but it didn't feel quite Simon right for this occasion. Don't get me wrong either, I haven't been vouching for catalyst much these days either, there certainly are flaws and reasons for not using it. Personally, I've been going for Web::Simple these days because it has the best dispatcher I've seen so far. I just felt that the arguments displayed against catalyst in this discussion were unfair. -- Eden Cardim Software Engineer Shadowcat Systems Ltd. http://www.shadowcat.co.uk http://blog.edencardim.com
Re: Recommendation for simple Web Frameworks
On Mon, Jan 10, 2011 at 10:00:39PM +, John Imison wrote:
Out of interest, does anyone use CGI::Application? What are the general
thoughts on that?
I've looked at it, but never used it because it seems utterly pointless.
It seems to be a fancy way of writing this ...
$actions = {
foo = \do_foo,
bar = \do_bar,
baz = \do_baz
};
if(my $action_sub = $actions-{$q-param('action')}) {
$action_sub-()
} else {
unknown_action_error()
}
--
header FROM_DAVID_CANTRELLFrom =~ /david.cantrell/i
describe FROM_DAVID_CANTRELLMessage is from David Cantrell
scoreFROM_DAVID_CANTRELL15.72 # This figure from experimentation
Re: Recommendation for simple Web Frameworks
On Mon, Jan 10, 2011 at 10:41:02PM +, Peter Edwards wrote: Indeed. I'm in a corporate environment where installing 70+ up to date CPAN modules is a non-trivial requirement. You don't have to be in a corporate environment for that to be a pain in the arse. On my own machines I don't really want to run the risk that one of those 70+ dependencies will break something else, nor do I particularly relish having a seperate build of perl with its own @INC sandbox for every application. Something with fewer dependencies makes it easier to either verify them before-hand, or figure out what screwed up and fix it. I needed to update our Twitter feeder recently and had to bail on the CPAN Moose OAuth Twitter for a simpler one purely for that reason. I use ttytter, which has pleasingly few dependencies. In fact IIRC I didn't need to install any at all. -- David Cantrell | Reality Engineer, Ministry of Information Do not be afraid of cooking, as your ingredients will know and misbehave -- Fergus Henderson
Re: Recommendation for simple Web Frameworks
David == David Cantrell da...@cantrell.org.uk writes: David You don't have to be in a corporate environment for that to David be a pain in the arse. On my own machines I don't really David want to run the risk that one of those 70+ dependencies will David break something else, nor do I particularly relish having a David seperate build of perl with its own @INC sandbox for every David application. It's pretty trivial to build and load perl modules somewhere other than the vendor perl lib directories where they might risk breaking the system. The only real reason you have to stay away from dependencies in a corporate environment is when it's enforced legally, otherwise, anyone with a gnu toolchain and a clue can build perl modules without remotely risking breaking the system. -- Eden Cardim Software Engineer Shadowcat Systems Ltd. http://www.shadowcat.co.uk http://blog.edencardim.com
Re: Recommendation for simple Web Frameworks
On 11 January 2011 20:12, Eden Cardim edencar...@gmail.com wrote: It's pretty trivial to build and load perl modules somewhere other than the vendor perl lib directories where they might risk breaking the system. The only real reason you have to stay away from dependencies in a corporate environment is when it's enforced legally, otherwise, anyone with a gnu toolchain and a clue can build perl modules without remotely risking breaking the system. The main issue is time needed to do all that, and maintenance problems. On top of that, if you need to stay up-to-date you need a local mirror and the permission to install it. And then deployment can be more difficult if you have more dependancies. Of course everything is possible, but it sounds fair to assume that simple means simple in learning, development, deployment, maintenance. And not only development. dams.
Re: Recommendation for simple Web Frameworks
On 11 Jan 2011, at 19:28, damien krotkine wrote: On 11 January 2011 20:12, Eden Cardim edencar...@gmail.com wrote: It's pretty trivial to build and load perl modules somewhere other than the vendor perl lib directories where they might risk breaking the system. The only real reason you have to stay away from dependencies in a corporate environment is when it's enforced legally, otherwise, anyone with a gnu toolchain and a clue can build perl modules without remotely risking breaking the system. The main issue is time needed to do all that, and maintenance problems. On top of that, if you need to stay up-to-date you need a local mirror and the permission to install it. And then deployment can be more difficult if you have more dependancies. Of course everything is possible, but it sounds fair to assume that simple means simple in learning, development, deployment, maintenance. And not only development. It's a pain in the ass.
Re: Recommendation for simple Web Frameworks
Simon == Simon Wistow si...@thegestalt.org writes: Simon In short - I don't really need the CRUD stuff from a Simon framework, I really just need the url based dispatch. I Simon played around with Catalyst (which I'm familiar with from 6A) Simon but it felt like it was a bit of a sledgehammer and that it Simon was (not unreasonably) tied to an ORM. You got the wrong impression, Catalyst isn't tied to anything, it's just a plugglable/configurable http dispatcher, it's as simple as any of the other perl web frameworks in that regard. It does have a larger user base for testing/contribution/support, I'd say that's the main advantage. -- Eden Cardim Software Engineer Shadowcat Systems Ltd. www.shadowcat.co.uk http://blog.edencardim.com
Re: Recommendation for simple Web Frameworks
Eden Cardim wrote: Simon == Simon Wistowsi...@thegestalt.org writes: Simon In short - I don't really need the CRUD stuff from a Simon framework, I really just need the url based dispatch. I Simon played around with Catalyst (which I'm familiar with from 6A) Simon but it felt like it was a bit of a sledgehammer and that it Simon was (not unreasonably) tied to an ORM. You got the wrong impression, Catalyst isn't tied to anything, it's just a plugglable/configurable http dispatcher, it's as simple as any of the other perl web frameworks in that regard. It does have a larger user base for testing/contribution/support, I'd say that's the main advantage. But the dependencies list *is* much larger for Catalyst. http://deps.cpantesters.org/?module=Dancer;perl=latest vs http://deps.cpantesters.org/?module=Catalyst::Runtime;perl=latest Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Recommendation for simple Web Frameworks
Matt == Matt Sergeant mserge...@messagelabs.com writes: Matt But the dependencies list *is* much larger for Catalyst. That's hardly the topic at hand. -- Eden Cardim Software Engineer Shadowcat Systems Ltd. http://www.shadowcat.co.uk http://blog.edencardim.com
Re: Recommendation for simple Web Frameworks
On Mon, 2011-01-10 at 18:42 -0200, Eden Cardim wrote: Matt == Matt Sergeant mserge...@messagelabs.com writes: Matt But the dependencies list *is* much larger for Catalyst. That's hardly the topic at hand. When the OP is looking for simple frameworks, it's a valid thing to take into consideration - something which installs quickly with minimal dependencies might be preferable. I doubt anyone is going to make the decision based solely on that, but it's another criterion. -- David Precious dav...@preshweb.co.uk (bigpresh) http://www.preshweb.co.uk/
Re: Recommendation for simple Web Frameworks
On Mon, Jan 10, 2011 at 08:25:37AM -0200, Eden Cardim said: Simon == Simon Wistow si...@thegestalt.org writes: You got the wrong impression, Catalyst isn't tied to anything, it's just a plugglable/configurable http dispatcher, it's as simple as any of the other perl web frameworks in that regard. It does have a larger user base for testing/contribution/support, I'd say that's the main advantage. You can see how I'd be confused given that the docs say Catalyst follows the Model-View-Controller (MVC) design pattern, allowing you to easily separate concerns, like content, presentation, and flow control, into separate modules. Now true that doesn't necessarily preclude me from not creating models but it does seem to imply that they are somewhat expected. My experience with most of the major web frameworks across 3 different languages has indicated that much of their utility is based on the automagic they provide. Magic requires a fair bit of convention-over-configuration or, at least, expects you to be doing things The Right Way[tm] and attempts to circumvent tend to lead to problems. And I'm fine with that - it's a good thing and for 90% of people it's probably the right thing. However I didn't want to be in the position where, somewhere down the line, I started having to wrap hashes in fake pseudo-Catalyst::Model classes in order to get stuff working with some component or plugin because the author of that (quite rightly) assumed that no fool would ever not be using models. [*] I may have the wrong impression but my experience with a large Catalyst app (TypePad) and reading the docs lead me to that impression. Other reasons for not going with Catalyst which may or may not be FUD: * Felt too heavy. I needed a very simple app and Catalyst seems designed for non-simple apps. * Bad experience with Catalyst based app start up times during development cycles (this is also true for Django and Rails FWIW) * Too many dependencies * Moose. I just don't like it - but that's just me. Don't get me wrong, I think Catalyst is great but it didn't feel quite right for this occasion. In the end I went with Dancer and I'm loving it so far - some more docs on the idiomatic way to deal with user creation, authentication and roles might be nice but I think I figured it all out pretty quickly. Thanks for the feedback though, Simon
Re: Recommendation for simple Web Frameworks
On 10/01/2011 9:13 PM, David Precious wrote: On Mon, 2011-01-10 at 18:42 -0200, Eden Cardim wrote: Matt == Matt Sergeantmserge...@messagelabs.com writes: Matt But the dependencies list *is* much larger for Catalyst. That's hardly the topic at hand. When the OP is looking for simple frameworks, it's a valid thing to take into consideration - something which installs quickly with minimal dependencies might be preferable. I doubt anyone is going to make the decision based solely on that, but it's another criterion. Out of interest, does anyone use CGI::Application? What are the general thoughts on that? Regards, John
Re: Recommendation for simple Web Frameworks
On 10 Jan 2011, at 20:42, Eden Cardim wrote: Matt == Matt Sergeant mserge...@messagelabs.com writes: Matt But the dependencies list *is* much larger for Catalyst. That's hardly the topic at hand. Of course it is. Are all the prereqs at the required level out there in the latest RHEL Enterprise? The forget using Catalyst in a more corporate environment.
Re: Recommendation for simple Web Frameworks
On 10 Jan 2011, at 22:00, John Imison wrote: On 10/01/2011 9:13 PM, David Precious wrote: On Mon, 2011-01-10 at 18:42 -0200, Eden Cardim wrote: Matt == Matt Sergeantmserge...@messagelabs.com writes: Matt But the dependencies list *is* much larger for Catalyst. That's hardly the topic at hand. When the OP is looking for simple frameworks, it's a valid thing to take into consideration - something which installs quickly with minimal dependencies might be preferable. I doubt anyone is going to make the decision based solely on that, but it's another criterion. Out of interest, does anyone use CGI::Application? What are the general thoughts on that? As a dispatcher, it's fine. DBIC+TT+CGI::App is a framework :)
Re: Recommendation for simple Web Frameworks
Matt == Matt Sergeant mserge...@messagelabs.com writes: Matt But the dependencies list *is* much larger for Catalyst. Indeed. I'm in a corporate environment where installing 70+ up to date CPAN modules is a non-trivial requirement. I needed to update our Twitter feeder recently and had to bail on the CPAN Moose OAuth Twitter for a simpler one purely for that reason. It's not always practicable even if we like Moose with deps (which most of us do). Regards, Peter http://perl.dragonstaff.co.uk
Re: Recommendation for simple Web Frameworks
On 10 Jan 2011, at 22:41, Peter Edwards wrote: Matt == Matt Sergeant mserge...@messagelabs.com writes: Matt But the dependencies list *is* much larger for Catalyst. Indeed. I'm in a corporate environment where installing 70+ up to date CPAN modules is a non-trivial requirement. I needed to update our Twitter feeder recently and had to bail on the CPAN Moose OAuth Twitter for a simpler one purely for that reason. It's not always practicable even if we like Moose with deps (which most of us do). Search for shipwright on your friendly neighbourhood intranet then blame Piers.
Re: Recommendation for simple Web Frameworks
On Mon, 2011-01-10 at 22:00 +, John Imison wrote: Out of interest, does anyone use CGI::Application? What are the general thoughts on that? It's called Titanium now isn't it? Seemed nice and simple when I last used it. signature.asc Description: This is a digitally signed message part
Re: Recommendation for simple Web Frameworks
On Mon, Jan 10, 2011 at 10:55:42PM +, Dave Hodgkinson wrote: On 10 Jan 2011, at 22:41, Peter Edwards wrote: Matt == Matt Sergeant mserge...@messagelabs.com writes: Matt But the dependencies list *is* much larger for Catalyst. Indeed. I'm in a corporate environment where installing 70+ up to date CPAN modules is a non-trivial requirement. I needed to update our Twitter feeder recently and had to bail on the CPAN Moose OAuth Twitter for a simpler one purely for that reason. It's not always practicable even if we like Moose with deps (which most of us do). Search for shipwright on your friendly neighbourhood intranet then blame Piers. Actually, Shipwright is one of ours (BPS's) --
Re: Recommendation for simple Web Frameworks
On 10 January 2011 22:59, Denny 2...@denny.me wrote: On Mon, 2011-01-10 at 22:00 +, John Imison wrote: Out of interest, does anyone use CGI::Application? What are the general thoughts on that? It's called Titanium now isn't it? Seemed nice and simple when I last used it. I'm working with CGI::App on a CMS that delivers a huge number of stories and audio-visual items internationally. It works, it's reliable and it's simple. CGI::App's been around a long time. That means other programmers have done your testing for you. These are all good things. It's always possible to rewrite something to the latest, coolest tech, but that doesn't mean it will work reliably, be cost-effective or can be grokked by your average programmer. There's a correlation there with whether your Ops department will allow you to install it :-| Regards, Peter
Re: Recommendation for simple Web Frameworks
On 10 Jan 2011, at 23:01, Jesse Vincent wrote: On Mon, Jan 10, 2011 at 10:55:42PM +, Dave Hodgkinson wrote: On 10 Jan 2011, at 22:41, Peter Edwards wrote: Matt == Matt Sergeant mserge...@messagelabs.com writes: Matt But the dependencies list *is* much larger for Catalyst. Indeed. I'm in a corporate environment where installing 70+ up to date CPAN modules is a non-trivial requirement. I needed to update our Twitter feeder recently and had to bail on the CPAN Moose OAuth Twitter for a simpler one purely for that reason. It's not always practicable even if we like Moose with deps (which most of us do). Search for shipwright on your friendly neighbourhood intranet then blame Piers. Actually, Shipwright is one of ours (BPS's) If only you knew what it's spawned.
Re: Recommendation for simple Web Frameworks
On 6 January 2011 20:04, Simon Wistow si...@thegestalt.org wrote: Before I write my own (or repurpose one of the hundred previosu ones I've written) does anyone have any recommendations? http://perldancer.org/ http://search.cpan.org/~beppu/Squatting/ http://mojolicious.org/ My feeling is that Dancer probably suits your stated requirements best. You get nice simple request routing, and the other stuff is better done using Plack middleware. /joel
Re: Recommendation for simple Web Frameworks
On Thu, Jan 6, 2011 at 11:17, Joel Bernstein j...@fysh.org wrote: On 6 January 2011 20:04, Simon Wistow si...@thegestalt.org wrote: Before I write my own (or repurpose one of the hundred previosu ones I've written) does anyone have any recommendations? [...] My feeling is that Dancer probably suits your stated requirements best. You get nice simple request routing, and the other stuff is better done using Plack middleware. *nod* Of all the light-weight frameworks, Dancer was the nicest to work with when I went through to evaluate them for pretty much exactly the use-case described. Daniel -- ✉ Daniel Pittman dan...@rimspace.net ⌨ dan...@rimspace.net (XMPP) ☎ +1 503 893 2285 ♻ made with 100 percent post-consumer electrons
Re: Recommendation for simple Web Frameworks
On 06/01/11 19:17, Joel Bernstein wrote: On 6 January 2011 20:04, Simon Wistowsi...@thegestalt.org wrote: Before I write my own (or repurpose one of the hundred previosu ones I've written) does anyone have any recommendations? http://perldancer.org/ I've been using Dancer to stitch together a fairly simple web front end to a heavier backend app, and also for an intranet reporting app. The docs are a bit sparse, but improving all the time and they did an advent calendar that gives you a good overview: http://advent.perldancer.org/2010 I've had no trouble understanding the code when trying to figure out how things work. The routing is simple enough, and it's easy to set up sessions, json responses for ajax-based services, REST via plugins etc. Has a Dancer::Test module too. The current 1.2 release is supposedly going to be kept stable through its lifetime. It hooks into plack simply enough and the starman server is supposed to provide good performance (it's certainly more than good enough for me). The plack debug plugin is handy, and there are some dancer-specific extensions for it. http://search.cpan.org/dist/Starman/ http://search.cpan.org/dist/Plack-Middleware-Debug/ http://search.cpan.org/search?query=plack+debug+dancermode=all -- Richard Huxton Archonet Ltd
Re: Recommendation for simple Web Frameworks
On Thu, Jan 6, 2011 at 8:04 PM, Simon Wistow si...@thegestalt.org wrote: So, it's been a while since I've done any kind of web stuff in Perl (although I was sitting behind Tatsuhiko when he was building the first Plack stuff so I'm at least aware of that). I want to build a web site. In Perl. It needs to be dynamic but it's unlikely to need a database - it will however be pulling data from another data store and putting stuff into job queues. In short - I don't really need the CRUD stuff from a framework, I really just need the url based dispatch. I played around with Catalyst (which I'm familiar with from 6A) but it felt like it was a bit of a sledgehammer and that it was (not unreasonably) tied to an ORM. Before I write my own (or repurpose one of the hundred previosu ones I've written) does anyone have any recommendations? Running under Plack/PSGI[*] seems like a good idea so let's make that a requirement (although it seems like writing a Plack binding for anything takes 3 lines of code and magically makes your system run 30 times faster and gives you free unicorn ponies every hour on the hour to boot). Some sort of authentication/role system would be nice too. OAuth support too. Can these be done via Plack middleware maybe? It looks like it. This is a recurring theme (for example: http://twitter.com/#!/clkao/status/27613002311 ) - I remember Tatsuhiko recommended against making it in middleware (http://groups.google.com/group/psgi-plack/browse_thread/thread/af584fff9a6629aa) - but maybe we could have something that is not a middleware - but is still reusable between frameworks? I am thinking about writing something that I could use in WebNano and ideally I would do something reusable. By the way - if you don't mind using something still very minimalistic - then you might try WebNano. At the core it is just 250 lines of code and really few dependencies implementing Namespace Matching (think Catalyst :Local dispatching) for PSGI/Plack based applications. Cheers, Zbigniew
Re: Recommendation for simple Web Frameworks
On Thu, Jan 06, 2011 at 07:04:13PM +, me said: Before I write my own (or repurpose one of the hundred previosu ones I've written) does anyone have any recommendations? Thanks, Dancer looks perfect. Is there a good rule of thumb with these things as to whether something should go in the middleware or not. My instinct would be: anything that requires application logic or config (like knowing how to connect to the datastore) should be in the app whereas stuff like, say, gzipping should be in the middleware with any blurry lines (OAuth support for example) handled using callbacks. Sounds about right?
Re: Recommendation for simple Web Frameworks
On Thu, Jan 6, 2011 at 9:39 PM, Simon Wistow si...@thegestalt.org wrote: On Thu, Jan 06, 2011 at 07:04:13PM +, me said: Before I write my own (or repurpose one of the hundred previosu ones I've written) does anyone have any recommendations? Thanks, Dancer looks perfect. Is there a good rule of thumb with these things as to whether something should go in the middleware or not. My instinct would be: anything that requires application logic or config (like knowing how to connect to the datastore) should be in the app whereas stuff like, say, gzipping should be in the middleware with any blurry lines (OAuth support for example) handled using callbacks. You can use App config in middlewares if you apply them in the application code (right before returning the callback). In Nblog I for serving the static files from location that is in the application config I use Plack::App::File (and combine it with my own application using Plack::App::URLMap) - in principle I could use any middleware in the same way. Is that too convoluted? -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/
Re: Recommendation for simple Web Frameworks
On Thu, Jan 06, 2011 at 08:39:06PM +, me said: with any blurry lines (OAuth support for example) handled using callbacks. Actually, since I'm being lazy - is there a good guide or an example for doing OAuth under Plack / Dancer / Plack+Dancer? I note that there's https://github.com/hidek/Plack-Middleware-Auth-OAuth/ via http://blog.plackperl.org/2010/04/hideks-plack-middleware-auth-oauth-at-master---github.html which is bit short on documentation and also claims to be on CPAN but doesn't seem to actually, you know, be there (and the test has spelling based syntax error in it, neither of which inspire confidence) and Plack::Middleware::Auth::OAuth2::ProtectedResource which is also somewhat short on documentation. There's also this http://advent.perldancer.org/2010/17 but that's authenticating a user against Twitter using OAuth Simon
Re: Recommendation for simple Web Frameworks
On Thursday 06 January 2011 19:04:13 Simon Wistow wrote: I want to build a web site. In Perl. It needs to be dynamic but it's unlikely to need a database - it will however be pulling data from another data store and putting stuff into job queues. In short - I don't really need the CRUD stuff from a framework, I really just need the url based dispatch. I played around with Catalyst (which I'm familiar with from 6A) but it felt like it was a bit of a sledgehammer and that it was (not unreasonably) tied to an ORM. I was going to step in with a somewhat biased recommendation of Dancer, but I'm happy to see that it's already been recommended :) Actually, since I'm being lazy - is there a good guide or an example for doing OAuth under Plack / Dancer / Plack+Dancer? Not that I'm aware of, but there should really! I think there needs to be a Dancer::Plugin::Auth::OAuth - I'll try to get round to writing one as soon as I have a chance, but there's a fair chance someone else might well do it in the meantime. By the way, you'll find the Dancer dev team (and some users, too :) ) on IRC in #dancer on irc.perl.org if you want to ask questions quickly. Cheers Dave P (bigpresh) -- David Precious dav...@preshweb.co.uk http://blog.preshweb.co.uk/www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedinwww.preshweb.co.uk/facebook www.preshweb.co.uk/identicawww.lyricsbadger.co.uk Programming is like sex. One mistake and you have to support it for the rest of your life. (Michael Sinz)
