[Catalyst] New stable and development versions on CPAN

[John Napiorkowski]

On Monday, December 23, 2013 9:19 AM, neil.lunn <neil at mylunn.id.au> wrote:

On 24/12/2013 1:20 AM, John Napiorkowski wrote:
> ---
> Thanks Neil, I think a lot of people sometimes forget that the Catalyst object is really in the end just a class.  --jnap
>
I tend to generally agree that a lot of "Catalyst::Plugin::*" stuff is a 
"giant bag of Blue meth" that we all need to ween ourselves off of. 
Config structures and logging implementation are always best 
"externalized" along with general Domain logic with any application. By 
"externalized" I mean, outside the "framework" in a manner that they 
just work when implemented by themselves, without the "framework's" help.

At the risk of entering into a rant, I prefer a class factory approach 
to applying "Roles/mixins" to plain classes. Something that the Java 
"POJO" crowd got right.

--
I think ideally well have something like Catalyst::Application that just
has a new method, and maybe Catalyst::Builder or similar that does the
job of instantiating the application in a given context (configuration, etc.)
SO yeah, I think we need to think carefully about the approach of extending
stuff just by slapping a role over it.  Sometimes its correct but other times
it just causes confusion.  Moving more stuff into middleware is a goal for 
Runner and hopefully that will start to reduce the overall code bulk and let
use figure out the cleanest refactoring approach that doesn't kill backcompat

---


Keen to fix up a lot of this stuff. As simply moving "::Plugin*" guff to 
applied roles, Probably code cahanges and new modules in preference to 
'Plugin', and Ideally having good DI on top of Catalyst. That is 
sensibly consumed. It would be nice to pull in config and service 
locators from something external and that was itself configuration file 
aware.

--
Regarding dependency injection, there's the long lost Bread::board branch
which I think has a lot of good stuff (and at least test cases).  I think
the approach I want to take here is to generalize what Catalyst wants from
A DI interface (probably start with just generalized what we do now, which
is like half a DI as it stands).  that way later on someone could just 
do an adaptor for the interface for BB.  I'm not currently sure that BB in
core is the correct long term approach since I am not 100% certain that Catalyst
will stay wedded to Moose (in core) over the term.  I was a big supporter of
the CataMoose project, but I also had an assumption that Perl would have core
MOP support by now to deal with some of the memory and speed issues.  Since that
looks like its now at least two years off give or take I think we should consider
alternatives if such ccan be done without breaking the bank.
--


BTW. Good work on the native file handle and psgi.streaming support, +If 
#miyagawa will patch up Plack::Util::content_length as suggested, then 
Catalyst in new release should work just the same as before but with new 
improvements and performance.

---
We need to write a test case and a proposed patch to help him along I think :)
If someone can do that I will go and push to get it included.

--john


Neil

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com


_______________________________________________
List: Catalyst at 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/