Re: [Catalyst] Random thoughts on helper class generation
I second Octavian's comments. Though I still chose Catalyst over the other Perl frameworks, when you spend copious amounts of time reading docs and learning how to use the Catalyst framework, to then be questioned why you are doing something the way you are in the IIRC because it's wrong or at least outdated and not the best method, when all you are doing is following what the documentation tells you to do, is rather frustrating to say the least, and a waste of everyone's time... which then makes you wonder, how good other framework's documentation is and if that would be easier , simpler and more up-to-date. It's not just the documentation / tutorials and how-to's either, it's even the error messages. Too bad that those people don't have the necessary time for that. That doesn't cover the cryptic, poorly written error / warning messages! There are clearly ridiculously clever people working on this project, but I feel sometimes they need to step back for a second and think... how could I explain this to a total idiot, verbose and verbatim documentation, error messages, tutorial and alike, are not the place for fiendishly clever one liners! Catalyst has a big advantage over the other frameworks other than just being an awesome piece of software and that's the community; it's friendly , accessible and a pleasure to be involved in, it's littered with seriously talented individuals at the top of their game, working in huge corporations with a vast wealth of experience and technical know-how, but the documentation lets this down and it shouldn't. Unless of course the goal of Catalyst isn't to make it accessible to the greenest of users regardless of their technical ability? -Original Message- From: Octavian Rasnita [mailto:octavian.rasn...@ssifbroker.ro] Sent: 27 January 2014 09:25 To: The elegant MVC web framework Subject: Re: [Catalyst] Random thoughts on helper class generation From: neil.lunn n...@mylunn.id.au On 27/01/2014 1:27 PM, John Napiorkowski wrote: Neil, I know the problem we have here, but honestly I think the solution is going to be more about having less stuff in Catalyst.pm rather than more... Hi John, Actually probably missed something in my intended context in the course of the rant. Couldn't agree more with that statement, truly less is more and I wasn't putting a shout out to either change 'Catalyst::Helper' or otherwise bloat things in 'Catalyst Core'. So I think we can agree that it is better to pull things out and delegate to more generic add-in's. I have seen in some reading terms and statements such as monolithic catalyst application ..., which is sadly a sad misnomer and seems more of an indictment on the development model of the authors than an actual problem of Catalyst itself. That said, it doesn't help today much :) Feel free to try a plugin and see what people think. Is a good way to shakeout new ideas. So largely a position on how many people are generally cargo culting the catalyst helper default files, which probably would have been a better title. And otherwise trying to get a feel for what other people were doing as typical, App, Controller, View, Model setups. As for the code, that was my way of saying here's one other way of doing it, what's yours? If anything, the only critique here regarding the helper templates is that new inductees are likely to come on board and just so things as they are in the manual, without much thought to what is actually happening. Hence the reference to getting logging set up under ConfigLoader, and so we show another approach. But not sure exactly what to do about making people think, and think differently, yet. I think a better documentation for Catalyst *written by those who know the internals very well* would be very helpful to solve this problem. Too bad that those people don't have the necessary time for that. I think the fact that Catalyst has too much magic is a reason why most beginners prefer Dancer or Mojolicious. Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ This Email and any attachments contain confidential information and is intended solely for the individual to whom it is addressed. If this Email has been misdirected, please notify the author as soon as possible. If you are not the intended recipient you must not disclose, distribute, copy, print or rely on any of the information contained, and all copies must be deleted immediately. Whilst we take reasonable steps to try to identify any software viruses, any attachments to this e-mail may nevertheless contain viruses, which our anti-virus software has failed to identify. You should therefore carry out your own anti-virus checks before opening any
Re: [Catalyst] Random thoughts on helper class generation
one of the problems is that once you have your chops, catalyst just gets out of your way, and you spend so little time in it compared to the real business logic and front end that most of the other problems you described vanish. In my opinion that is. But I tend to ignore the new great things until well after they're considered new. It's basically my main coping strategy :) On 30/01/2014, at 11:32 PM, Craig Chant wrote: Unless of course the goal of Catalyst isn't to make it accessible to the greenest of users regardless of their technical ability? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Random thoughts on helper class generation
==JOHN One of my reach goals for Catalyst6 is to have a separate project like Catalyst'Stack or some such that would be aimed at having more opinions and setup, to make it easier for newcomers to understand. Ideally we'd have 3 or 4 non trivial but understandable and well scoped example applications that would basically be the test cases for it and they'd be there to help people get started. Volunteers very welcomed. I'll try to spend more time blogging about internals. I will say that the more I see other people stepping up to take on Catalyst quests (or suggesting solid ones and taking ownership of it) the more I will feel comfortable to spend time on docs. I know it might seem hard to get started, but two years ago I felt pretty confused but I just took on some basic tasks and over time started to feel my away around. If you put your mind to it, choose something and be willing to chew on it for a year or so and you will also pick up the code. For me I wanted to see better support for async in Catalyst. There was like 5 or 6 branches all trying to do this in the repo but nothing ever got production ready. It took a while but we now have something basic that works and didn't break back compat. So find something about Catalyst that really bothers you and think about it. Two bigger things that come to mind, if nothing on the quest list looks good to you, is some way to move forward on app/ctx split or migrating all the existing dispatch types to use chaining under th hood (there's code for this, t0m knows where it is, just never got enough testing). The bigger the community of contribs are, the more information will get shared. I know its hard for a lot of us since all the big brains have moved mostly on to other things, but we will just have to manage. Its not going to be easy for the first bunch of us to figure all this out, but we can make it easier for the next group behind us and try to put Catalyst on a sustainable path were it remains relevant well into the future. ==/JOHN On Thursday, January 30, 2014 6:33 AM, Craig Chant cr...@homeloanpartnership.com wrote: I second Octavian's comments. Though I still chose Catalyst over the other Perl frameworks, when you spend copious amounts of time reading docs and learning how to use the Catalyst framework, to then be questioned why you are doing something the way you are in the IIRC because it's wrong or at least outdated and not the best method, when all you are doing is following what the documentation tells you to do, is rather frustrating to say the least, and a waste of everyone's time... which then makes you wonder, how good other framework's documentation is and if that would be easier , simpler and more up-to-date. It's not just the documentation / tutorials and how-to's either, it's even the error messages. Too bad that those people don't have the necessary time for that. That doesn't cover the cryptic, poorly written error / warning messages! There are clearly ridiculously clever people working on this project, but I feel sometimes they need to step back for a second and think... how could I explain this to a total idiot, verbose and verbatim documentation, error messages, tutorial and alike, are not the place for fiendishly clever one liners! Catalyst has a big advantage over the other frameworks other than just being an awesome piece of software and that's the community; it's friendly , accessible and a pleasure to be involved in, it's littered with seriously talented individuals at the top of their game, working in huge corporations with a vast wealth of experience and technical know-how, but the documentation lets this down and it shouldn't. Unless of course the goal of Catalyst isn't to make it accessible to the greenest of users regardless of their technical ability? -Original Message- From: Octavian Rasnita [mailto:octavian.rasn...@ssifbroker.ro] Sent: 27 January 2014 09:25 To: The elegant MVC web framework Subject: Re: [Catalyst] Random thoughts on helper class generation From: neil.lunn n...@mylunn.id.au On 27/01/2014 1:27 PM, John Napiorkowski wrote: Neil, I know the problem we have here, but honestly I think the solution is going to be more about having less stuff in Catalyst.pm rather than more... Hi John, Actually probably missed something in my intended context in the course of the rant. Couldn't agree more with that statement, truly less is more and I wasn't putting a shout out to either change 'Catalyst::Helper' or otherwise bloat things in 'Catalyst Core'. So I think we can agree that it is better to pull things out and delegate to more generic add-in's. I have seen in some reading terms and statements such as monolithic catalyst application ..., which is sadly a sad misnomer and seems more of an indictment on the development model of the authors than an actual problem of Catalyst itself. That said, it doesn't help today
Re: [Catalyst] Random thoughts on helper class generation
From: neil.lunn n...@mylunn.id.au On 27/01/2014 1:27 PM, John Napiorkowski wrote: Neil, I know the problem we have here, but honestly I think the solution is going to be more about having less stuff in Catalyst.pm rather than more... Hi John, Actually probably missed something in my intended context in the course of the rant. Couldn't agree more with that statement, truly less is more and I wasn't putting a shout out to either change 'Catalyst::Helper' or otherwise bloat things in 'Catalyst Core'. So I think we can agree that it is better to pull things out and delegate to more generic add-in's. I have seen in some reading terms and statements such as monolithic catalyst application ..., which is sadly a sad misnomer and seems more of an indictment on the development model of the authors than an actual problem of Catalyst itself. That said, it doesn't help today much :) Feel free to try a plugin and see what people think. Is a good way to shakeout new ideas. So largely a position on how many people are generally cargo culting the catalyst helper default files, which probably would have been a better title. And otherwise trying to get a feel for what other people were doing as typical, App, Controller, View, Model setups. As for the code, that was my way of saying here's one other way of doing it, what's yours? If anything, the only critique here regarding the helper templates is that new inductees are likely to come on board and just so things as they are in the manual, without much thought to what is actually happening. Hence the reference to getting logging set up under ConfigLoader, and so we show another approach. But not sure exactly what to do about making people think, and think differently, yet. I think a better documentation for Catalyst *written by those who know the internals very well* would be very helpful to solve this problem. Too bad that those people don't have the necessary time for that. I think the fact that Catalyst has too much magic is a reason why most beginners prefer Dancer or Mojolicious. Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Random thoughts on helper class generation
On Monday, January 27, 2014 3:25 AM, Octavian Rasnita octavian.rasn...@ssifbroker.ro wrote: From: neil.lunn n...@mylunn.id.au On 27/01/2014 1:27 PM, John Napiorkowski wrote: Neil, I know the problem we have here, but honestly I think the solution is going to be more about having less stuff in Catalyst.pm rather than more... Hi John, Actually probably missed something in my intended context in the course of the rant. Couldn't agree more with that statement, truly less is more and I wasn't putting a shout out to either change 'Catalyst::Helper' or otherwise bloat things in 'Catalyst Core'. So I think we can agree that it is better to pull things out and delegate to more generic add-in's. I have seen in some reading terms and statements such as monolithic catalyst application ..., which is sadly a sad misnomer and seems more of an indictment on the development model of the authors than an actual problem of Catalyst itself. That said, it doesn't help today much :) Feel free to try a plugin and see what people think. Is a good way to shakeout new ideas. So largely a position on how many people are generally cargo culting the catalyst helper default files, which probably would have been a better title. And otherwise trying to get a feel for what other people were doing as typical, App, Controller, View, Model setups. As for the code, that was my way of saying here's one other way of doing it, what's yours? If anything, the only critique here regarding the helper templates is that new inductees are likely to come on board and just so things as they are in the manual, without much thought to what is actually happening. Hence the reference to getting logging set up under ConfigLoader, and so we show another approach. But not sure exactly what to do about making people think, and think differently, yet. I think a better documentation for Catalyst *written by those who know the internals very well* would be very helpful to solve this problem. Too bad that those people don't have the necessary time for that. I think the fact that Catalyst has too much magic is a reason why most beginners prefer Dancer or Mojolicious. Octavian ==JOHN Ha, but I did try with this years catalyst advent to pull back the curtain, but its never bad to say more. I think the key here is to focus on the good bits, and try to make it better (the way we interface with PSGI and all that). That said, if we move toward a version 6, I'd probably spend some time discussing the general architecture and the design patterns around it. Yeha, the helper templates are a bit long in the tooth. I'd actually prefer a separate project for project builders, one that could be shared across frameworks and that would make it easy for people to share project templates, even on github for example. There's like 10 of these of CPAN but obviously we've not hit the sweet spot yet, found the 'PSGI of project builders' since everyone still does their own thing. Personally I just us bash myself. One problem with the project builders is that it makes it easy to go to far and you end up with complex bunch of stuff only you understand. my guess is that is the core of the problem. I personally don't have time for any of the helpers, but if someone stepped up and wanted to modernize a bit I'd be happen to advise. Otherwise I do have a side project for a project builder but not sure if its going to make sense for others as it does for me, John ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Random thoughts on helper class generation
Neil,
I know the problem we have here, but honestly I think the solution is going to
be more about having less stuff in Catalyst.pm rather than more... Ideally the
application class would be a simple object rather than something that did a lot
of setup and configuration stuff, something more like
(my $app = Catalyst::Builder
-build(MyApp))-to_app;
Where the builder is responsible for reading any configuration and doing and
inversion of control games to provide whatever the MyApp application needed to
startup. That way we separate the concerns and simplify the code. Right now
we often run into issues where the order of setup and configuration gets wonky.
I think we can solve this with a standard design pattern,
That said, it doesn't help today much :) Feel free to try a plugin and see
what people think. Is a good way to shakeout new ideas.
John
On Friday, January 24, 2014 8:42 PM, neil.lunn n...@mylunn.id.au wrote:
On 25/01/2014 10:58 AM, neil.lunn wrote:
Hi all,
Was just thinking through setting up various project minting files and
got to looking at the default Catalyst app layout from the helper.
Specifically I wondered how much the defaults were just being cargo
culted, and specifically addressing my dislike for overuse of inline
__PACKAGE__ calls when we have Moose and BUILD available. So random
musings below:
Oops. Big fail. Forgot the most important bit. See edit
Here's a sensible base class for the App context:
package Catalyst::BaseClass;
use Moose;
use namespace::autoclean;
use Catalyst::Runtime 5.80;
use Catalyst qw/ PluginLoader /; # Should be all we need
extends 'Catalyst';
our $VERSION = '0.01';
sub hook_config {
my $self = shift;
my $class = ref($self);
# Set some basic defaults
return {
name = $class,
enable_catalyst_header = 1, # Send X-Catalyst header
};
}
sub hook_logger {
# Do nothing by default. Setup will take care of it.
}
sub BUILD {
my $self = shift;
my $class = ref($self);
unless ( $self-setup_finished ) {
# Setup Config
$self-config(
%{ $self-hook_config }
);
# Place a hook to hang a logger on before setup is called
$self-hook_logger();
$class-setup();
}
}
As you can see by the hook methods, this was take 2 where I was
abstracting my personal cause from the general base class. By
placing the hooks in you can abstract in your application, as in:
package YourApp::Web;
use Moose;
use namespace::autoclean;
extends 'Catalyst::BaseClass';
our $VERSION = '0.01';
our $load_class = \Plack::Util::load_class;
around 'hook_config' = sub {
my $orig = shift;
my $self = shift;
my $class = ref($self);
my $basename = $class;
$basename =~ s/::.+//g;
use Hash::Merge qw/merge/;
# Setup Config
my $configclass = $load_class-( ${basename}::Config );
return merge( $self-$orig, $configclass-config || {} );
};
override 'hook_logger' = sub {
my $self = shift;
# Optional logger from class
my $logger = $self-config-{Logger};
if ( defined $logger ) {
die Config Logger requires a Class key
unless $logger-{Class};
my $logclass = $load_class-( $logger-{Class} );
$self-log( $logclass-new( @{ $logger-{Config} || [] } ) );
$self-log-debug( qq/Initialized logger: $logclass/ );
}
};
Now, realistically even the *second* and extended implementation is
still notably generic and *for me* this is even enough to place as a
*base class* to every application as this is how I will lay things
out. Plack::Util seems to be a fair assumption to be loaded as the end
result is a PSGI app, and Plack::Runner is going to pull this in. For
the nosy, the Logger class in this case is a mere wrapper around
Log::Log4perl in this case, and would only get the logger instance if
it had already been initialized. You can (and I do) set up Plack
middleware to do the same thing, making the same logger available to
other PSGI parts that might be used in your application, all without
needing to wrap context to get at the logger, or explicitly call
Log::Log4pperl::get_logger as we might just want to change that to a
different logger at some stage.
So general thoughts are:
1. Have a config class that is external to Catalyst logic. You can use
it elsewhere without hassle.
2. Have a hook to hang that config on and get it early; because
3. Hang a logger on a hook before 'setup' is called so you can get the
startup logging on debug
4. Pull in the plugins from Config so there isn't a need to keep
modifying that code in the context class for every app
Also minimising the selection of Plugins. I do try to keep this to
session and auth stuff for convenience, and again have these as just
thin layers over Plack Middleware. Other things can be delegated to
role applicator stuff, which I haven't typed in here.
Anyone else have thoughts? Alternate favourite methods for layout?
---
Re: [Catalyst] Random thoughts on helper class generation
On 27/01/2014 1:27 PM, John Napiorkowski wrote:
Neil,
I know the problem we have here, but honestly I think the solution is going to
be more about having less stuff in Catalyst.pm rather than more...
Hi John,
Actually probably missed something in my intended context in the course
of the rant.
Couldn't agree more with that statement, truly less is more and I
wasn't putting a shout out to either change 'Catalyst::Helper' or
otherwise bloat things in 'Catalyst Core'. So I think we can agree that
it is better to pull things out and delegate to more generic add-in's.
I have seen in some reading terms and statements such as monolithic
catalyst application ..., which is sadly a sad misnomer and seems more
of an indictment on the development model of the authors than an actual
problem of Catalyst itself.
That said, it doesn't help today much :) Feel free to try a plugin and see
what people think. Is a good way to shakeout new ideas.
So largely a position on how many people are generally cargo culting
the catalyst helper default files, which probably would have been a
better title. And otherwise trying to get a feel for what other people
were doing as typical, App, Controller, View, Model setups.
As for the code, that was my way of saying here's one other way of
doing it, what's yours?
If anything, the only critique here regarding the helper templates is
that new inductees are likely to come on board and just so things as
they are in the manual, without much thought to what is actually
happening. Hence the reference to getting logging set up under
ConfigLoader, and so we show another approach. But not sure exactly
what to do about making people think, and think differently, yet.
John
On Friday, January 24, 2014 8:42 PM, neil.lunn n...@mylunn.id.au wrote:
On 25/01/2014 10:58 AM, neil.lunn wrote:
Hi all,
Was just thinking through setting up various project minting files and
got to looking at the default Catalyst app layout from the helper.
Specifically I wondered how much the defaults were just being cargo
culted, and specifically addressing my dislike for overuse of inline
__PACKAGE__ calls when we have Moose and BUILD available. So random
musings below:
Oops. Big fail. Forgot the most important bit. See edit
Here's a sensible base class for the App context:
package Catalyst::BaseClass;
use Moose;
use namespace::autoclean;
use Catalyst::Runtime 5.80;
use Catalyst qw/ PluginLoader /; # Should be all we need
extends 'Catalyst';
our $VERSION = '0.01';
sub hook_config {
my $self = shift;
my $class = ref($self);
# Set some basic defaults
return {
name = $class,
enable_catalyst_header = 1, # Send X-Catalyst header
};
}
sub hook_logger {
# Do nothing by default. Setup will take care of it.
}
sub BUILD {
my $self = shift;
my $class = ref($self);
unless ( $self-setup_finished ) {
# Setup Config
$self-config(
%{ $self-hook_config }
);
# Place a hook to hang a logger on before setup is called
$self-hook_logger();
$class-setup();
}
}
As you can see by the hook methods, this was take 2 where I was
abstracting my personal cause from the general base class. By
placing the hooks in you can abstract in your application, as in:
package YourApp::Web;
use Moose;
use namespace::autoclean;
extends 'Catalyst::BaseClass';
our $VERSION = '0.01';
our $load_class = \Plack::Util::load_class;
around 'hook_config' = sub {
my $orig = shift;
my $self = shift;
my $class = ref($self);
my $basename = $class;
$basename =~ s/::.+//g;
use Hash::Merge qw/merge/;
# Setup Config
my $configclass = $load_class-( ${basename}::Config );
return merge( $self-$orig, $configclass-config || {} );
};
override 'hook_logger' = sub {
my $self = shift;
# Optional logger from class
my $logger = $self-config-{Logger};
if ( defined $logger ) {
die Config Logger requires a Class key
unless $logger-{Class};
my $logclass = $load_class-( $logger-{Class} );
$self-log( $logclass-new( @{ $logger-{Config} || [] } ) );
$self-log-debug( qq/Initialized logger: $logclass/ );
}
};
Now, realistically even the *second* and extended implementation is
still notably generic and *for me* this is even enough to place as a
*base class* to every application as this is how I will lay things
out. Plack::Util seems to be a fair assumption to be loaded as the end
result is a PSGI app, and Plack::Runner is going to pull this in. For
the nosy, the Logger class in this case is a mere wrapper around
Log::Log4perl in this case, and would only get the logger instance if
it had already been initialized. You can (and I do) set up Plack
middleware to do the same thing, making the same logger available to
other PSGI parts that might be used in your application, all without
needing to wrap context to get at the logger, or explicitly call
