http://www.catalystframework.org/calendar/2014
I don't have articles to cover 25 days and could use a hand! I can commit to doing articles on each new feature and a review of the current development branch "Holland". That's about 10 articles. The rest I could really use some contrib.
Thanks!
jnap
| | | |
| | |
Hello Catalyst Lovers and Users!
Let's see if we can get one more release of Catalyst out the door in time for Advent 2014 (see 2013 if you are not familiar)!
For this release we've moved issue tracking from Questhub to Github Issues. Questhub is fantastic but more people already have Github accounts, and Issues integrates pretty well with Github so its a no brainer to try. Here's the target list:
https://github.com/perl-catalyst/catalyst-runtime/issues
Mostly we have a collection of what I think are small and easy wins, including a few things around PSGI integration. Two items of note would be:
https://github.com/perl-catalyst/catalyst-runtime/issues/53
Which is a ticket to extract the component lookup code and clarify the lookup interface. The goal here is to make improving componet lookup and make something like Bread::Board integration easier down the road.
https://github.com/perl-catalyst/catalyst-runtime/issues/55
This is more of a research task where we want to find out what things we need to change to make sharing Catalyst session and authentication information with other PSGI applications mounted under a Catalyst controller. This has impact on Catalyst Six planning and compatibility.
So that's what we target for Holland, but of course your documentation fixes and bug patches are always welcome (check with me if you should branch off holland or master)
So the repository is open, and issues are ready for your votes / comments / complaints!
Take it slow - jnap
P.S. Why 'Holland'? As in the past I've codenamed the next release of Catalyst after a rare or endangered domesticated animal. In this case I've choosen the Holland chicken, which was bred right here in the USA and has a lot of great characteristics for the home chicken keeper and you can read more here: http://www.livestockconservancy.org/index.php/heritage/internal/holland
I have one of these birds myself and she's the favorite of all my older chickens. In fact she's amazingly friendly and has oftened choosen to hunt about in the grass near where I or my wife are working in the garden. A great bird to have particularly if you are in the North (she's quite cold hardy) and have the land to let her forage. As an added plus her black and white coloration gives her a edge against predators that hunt by sight.
| | | |
| | |
Morning Catalyst Programmers and Users!
I'm pleased to announced that the current development branch of Catalyst has been deemed stable and ready for use. This release of Catalyst has focused on stablizing features introduced in earlier version, but it has the usually accompaniment of new features and documentation improvements. You can see the full changelog here, but the summary is:
-- Default log level is now Info, not Debug.
-- Stash is now a PSGI middleware component.
-- Encoding plugin code has been merged into Catalyst.pm
-- Some cleanup to remove code supporting long depracated options such as the PSGI engine and support for finding the PSGI env in the Engine object.
As usual I hope you all upgrade, test it out and shout out if you run into issues. The expectation here is that we'd be quite compatible with any release of Catalyst in the last two years, and that older versions of Catalyst should be upgradable as long as you follow the Delta file changes and changelog recommendations.
Expect to see goal setting and a new development branch cut between now and CPAN day!
| | | |
| | |
The PSGI specification describes middleware as:
"A middleware component takes another PSGI application and runs it. From the perspective of a server, a middleware component is a PSGI application. From the perspective of the application being run by the middleware component, the middleware is the server. Generally, this will be done in order to implement some sort of pre-processing on the PSGI environment hash or post-processing on the response."
The idea here is that your request / response cycle could pass through a number of middleware tranformations as it moves throught your application 'onion' one layer at a time. Ideally each middleware element in the stack is absolutely independent from any other. This would promote an application design that was strongly decoupled and yet because the PSGI specification it so simple, relatively easy to understand and follow and maintain.
In this ideal setup middleware would not be dependent on where it sits in the stack (it would not be dependent of another bit of middleware earlier in the cycle, for example).
In practice its become common to build middleware that is a small unit of common functionality intended to be consumed at some later point in the application. For example we have middleware likePlack::Middleware::Session which creates a session object typically used in your programming logic as part of your larger application. Although doing this violates the purity of middleware, there's a tremendous seduction to take this approach, since it offers the possibility to share common bits of funtionality across different web development frameworks. This reduces the need for every framework to build its own common services and promotes interoperability, and pools scarce developer resources for maintainance tasks. For example, one in theory could have a Web::Simple application and a Catalyst::Runtime application running together, and using Plack::Middleware::Session to share a logged in user session.
In this way we tangle the notion of middleware with your application at large, and in a real sense your application become dependent on the middleware in a way that can easily turn into a nasty structual dependency.
I've lately said that the future of Catalyst::Runtime is middleware. If so, what can be do to make sure our approach minimizes the problems outlined above? One approach we can take to mitigate this risk is to make sure that your middleware alone is responsible for providing an interface to the functionality it encapsulates. For example, lets look at some recent middleware written for Catalyst::Runtime which is middleware intended to encapsulate the functionality of the Catalyst stash. Here's a naive version:
use strict;
use warnings;
package Catalyst::Middleware::Stash;
use base 'Plack::Middleware';
use Carp 'croak';
sub call {
my ($self, $env) = @_;
$env->{"Catalyst.Stash"} ||= +{};
return $self->app->($env);
}
and in Catalyst::Runtime we'd change the stash method to look like this:
sub stash {
my $c = shift;
if (@_) {
my $new_stash = @_ > 1 ? {@_} : $_[0];
croak('stash takes a hash or hashref') unless ref $new_stash;
foreach my $key ( keys %$new_stash ) {
$c->request->env->{"Catalyst.Stash"}->{$key} = $new_stash->{$key};
}
}
return $c->request->env->{"Catalyst.Stash"};
}
So in this version we just move the stash hashref to the PSGI env. We expose the raw hashref and expect the consuming application to use it properly. This would work for Catalyst, but is poorly encapsulated and prone to misuse. Let's improve it a bit.
use strict;
use warnings;
package Catalyst::Middleware::Stash;
use base 'Plack::Middleware';
use Carp 'croak';
sub generate_stash_closure {
my $stash = shift || +{};
return sub {
if(@_) {
my $new_stash = @_ > 1 ? {@_} : $_[0];
croak('stash takes a hash or hashref')
unless ref $new_stash;
foreach my $key ( keys %$new_stash ) {
$stash->{$key} = $new_stash->{$key};
}
}
$stash;
};
}
sub call {
my ($self, $env) = @_;
$env->{"Catalyst.Stash"}
||= generate_stash_closure($env);
return $self->app->($env);
}
In this version of the middleware we assign a PSGI env key the stash functionality wrapped in a coderef. Basically we just converted the Catalyst::Runtime method 'stash' to be a coderef. This would actually work. To bring in into Catalyst.pm we'd need code something like:
sub stash {
my $c = shift;
$c->request->env->{"Catalyst.Stash"}->(@_);
}
So although we are better off because we encapsulated behind the method what a stash is and how its altered we still have onerous structural bindings. We see need to get the raw PSGI env. A simple miss-spelling still breaks the whole thing! Lets try to improve it a bit.
use strict;
use warnings;
package Catalyst::Middleware::Stash;
use base 'Plack::Middleware';
use Carp 'croak';
our $VERSION = "0.001";
sub PSGI_KEY { "Catalyst.Stash.$VERSION" };
sub generate_stash_closure {
my $stash = shift || +{};
return sub {
if(@_) {
my $new_stash = @_ > 1 ? {@_} : $_[0];
croak('stash takes a hash or hashref')
unless ref $new_stash;
foreach my $key ( keys %$new_stash ) {
$stash->{$key} = $new_stash->{$key};
}
}
$stash;
};
}
sub _init_stash {
my ($self, $env) = @_;
return $env->{+PSGI_KEY} ||=
generate_stash_closure;
}
sub call {
my ($self, $env) = @_;
$self->_init_stash($env);
return $self->app->($env);
}
So here we encapsulated the PSGI environment key behind a method. This solves the mistyping issue. We also took the opportunity to refactor how the stash get initialized. Here's how it might be used in Catalyst:
use Catalyst::Middleware:Stash;
sub stash {
my $c = shift;
$c->request->env->{Catalyst::Middleware::Stash::PSGI_KEY}->(@_);
}
Small change, but that's better since we eliminated the spelling error problem and we are setup so that if we need to change the stash key, we can do so without breaking people's code (since the key name is encapsulated behind a method which comes from the middleware). But I think we can make it even better.
use strict;
use warnings;
package Catalyst::Middleware::Stash;
use base 'Plack::Middleware';
use Exporter 'import';
use Carp 'croak';
our $VERSION = "0.001";
our @EXPORT_OK = qw(stash get_stash);
sub PSGI_KEY { "Catalyst.Stash.$VERSION" };
sub get_stash { return shift->{+PSGI_KEY} }
sub stash {
my ($host, @args) = @_;
return get_stash($host->env)->(@args);
}
sub generate_stash_closure {
my $stash = shift || +{};
return sub {
if(@_) {
my $new_stash = @_ > 1 ? {@_} : $_[0];
croak('stash takes a hash or hashref')
unless ref $new_stash;
foreach my $key ( keys %$new_stash ) {
$stash->{$key} = $new_stash->{$key};
}
}
$stash;
};
}
sub _init_stash {
my ($self, $env) = @_;
return $env->{+PSGI_KEY} ||=
generate_stash_closure;
}
sub call {
my ($self, $env) = @_;
$self->_init_stash($env);
return $self->app->($env);
}
In this final version we've completely encapsulated the stash interface and offered two exports to ease use if so desired. This works better than any method that hangs directly off the PSGI env since the client code is not responsible for knowing HOW to access $env. All that is needed is a valid PSGI env, the access and logic is completely on the middleware side. Here's one way this could be used in Catalyst:
use Catalyst::Middleware:Stash 'get_stash';
sub stash {
my $c = shift;
return get_stash($c->request->env)->(@_);
}
Alternatively we offer a 'stash' method that can be invoked on an object that does a method called env. As it happens most common PSGI frameworks do this. Here's an example using a simple very basic PSGI application:
use Plack::Request;
use Catalyst::Middleware::Stash 'stash';
my $app = sub {
my $env = shift;
my $req = Plack::Request->new($env);
my $stashed = $req->stash->{in_the_stash}; # Assume the stash was previously populated.
return [200, ['Content-Type' => 'text/plain'],
["I found $stashed in the stash!"]];
};
So in this last approach we've managed to encapsulate the interface such that the consumer is barely aware that we are using the PSGI env at all. Give how common it is to expose a method 'env' on a request object this approach could achieve both the goal of simplicity as well as strong encapsulation of the behavior.
Ultimately if we are going to migrate more core Catalyst::Runtime functionality into middleware, we need to take care that we are not making a messy and error prone interface. If we do this correctly I think we can end up with code that is more flexible, easy to understand and maintain as well as contribute to the great PSGI middleware ecosystem.
| | | |
| | |
Hi Catalyst stakeholders!
There was a lengthy discussion on IRC about Catalyst debug mode, log debugging and how it possibly relates to enviroment. Based on this we created notes on questhub and I cut a branch off Ancona and gave it a first pass. I'll blog more later but here is the early access information:
The quest: https://questhub.io/realm/perl/quest/53ab38d4b587a416570000d9
The proposed branch: https://github.com/perl-catalyst/catalyst-runtime/pull/41
Ideally comments would be left on the github pull request, but I'll also be checking the mailing list and am often on IRC.
| | | |
| | |
Howdy Catalyst Lovers!
Here's a quick update on things that have been happening with Catalyst recently. On the stable branch we've had a bunch of updates to improve how the new support for the Plack http exception middleware works. We've also had a bunch of documention and test case fixes as well as a big improvement to the way Catalyst::Log aborts logging.
See the full most recent stable changelog: https://metacpan.org/source/JJNAPIORK/Catalyst-Runtime-5.90065/Changes
On the development side we've had two releases for Ancona. There's a few more changes to how we support HTTP style exceptions which I consider a little too big for a stable release. However the biggest change so far is that we've moved the Catalyst stash from Catalyst.pm into Plack Middleware. If you just use the stash you should not experience any issues. This change means that your custom middleware and any applications you mount to Catalyst endpoints can now share information placed in the stash. This is intended to improve interoperability between Catalyst and other PSGI aware application running together in a single process. It is also a good testbed for the idea 'everything in Catalyst should be middleware' which is the ultimate goal and aim of current development efforts. Hopefully Ancona will see a bit more of Catalyst migrate to middleware before its cycle is run.
Here's the Ancona changelog: https://metacpan.org/source/JJNAPIORK/Catalyst-Runtime-5.90069_002/Changes up til today.
Thanks for tuning in!
| | | |
| | |
Howdy All,
One of the main ongoing themes of discussion around Perl Catalyst is to determine a mid to long term roadmap for where the platform is going. Over the past 18 months we've primarily worked on tasks around improving how Catalyst works with its PSGI underpinnings and we've also tried to graft in a number of features that one expects to come out of the box in a modern web framework from 2014. However this work has not addressed a larger question, which is what is Catalyst going to look like 2, 5 or even 10 years from now?
Another theme I hear a lot is that people find it hard to get the kind of documentation they need to go beyond the basic tutorial. Although there's a lot of ad hoc stuff (All the advent articles, and random blogs, etc.) and there's a number of useful code examples on Github it would be great if there was some sort of structured documentation that filled a gap between the introduction tutorial and the source code.
Aimed at both these issues is a new documentation project just getting started: https://github.com/perl-catalyst/Catalyst-Components-Concepts-Cases
This documentation project is intended to help people understand Catalyst in greater detail once they have mastered the basics but still find a lot of stuff confusing. Additionally, once we understand well what Catalyst is today, we can start to contrast what it might be tomorrow. For example, a comprehensive document regarding Catalyst.pm should serve as a good jumping off point for documenting what we'd change to improve matters in Catalyst 6 and beyond.
This project is just an outline right now, and I am hoping to let you, the community, help me identity all the topics we should cover. Feel free to fork the repo and send your pull requests!
| | | |
| | |
Morning programmers and well wishers!
So if you ever said, "I'll buy John a beer when we meet at YACP for all the open source contribs he's done over the years..." I'd rather you head over to my buddies fantasy TV show Kickstarter and consider a pledge.
This is a fantasy TV show with my good friend Skip Lipman who you might recognize if you've every seen a documentary called "Darkon" (was about LARPing in Baltimore). Skip is a hard core fantasy and roleplaying guy who makes his own armor and weapons and generally lives it by his rules. This is his big roll of the dice to leap up and I am trying to not let him down. So help me out if you can!
John
| | | |
| | |
Hello Catalyst Stakeholders!
Well, I've been quite busy and since nobody else (hint! hint!) stepped up to stick a fork in our goals for the next release of Catalyst, I guess I will just go ahead. The questhub list is here, and is the placewhere you should go to add comments and vote for the tasks you personally favor.
https://questhub.io/realm/perl/explore/latest/tag/ancona
Failing to vote means I get to amuse myself.
Since I last proposed these in Febuary I pared down the list a bit in order to focus on the items I think we have the best chance of completing an that seem to have the greatest interest (or are most needed in the framework to move things forward).
So there's a few things related to content negotiation, which I think is important given how much we are moving toward a web services driven world. We also want to continue refactoring the code and pulling out bits into standalone plugins or possibly middleware. As usual we have a few general code improvements, such as better integration of the unicode work did last year, migrating to more favored libraries for common tasks, and the ever present, "it should have been this way from the start, doh!"
We also have a nice task for a newbie, if you want to contrib but think you are not good enough to cut it (that's me calling you out, chicken!) And lastly there's a task to consolidate and review the big list of things we are deprecating for the Catalyst 6 cycle. That's an important task since I want to take advantage of the new major version to dump stuff nobody uses (or should use) and give us the freedom to change code in deeper ways then we might normally do.
In any case, the branch is open and the challenge has gone forth. Who will step up?
About the Ancona Duck: Ancona's are mild tempered ducks that can be great self foragers given space and tend to be decent egg layers (over 250 eggs a year not uncommon). They probably get the forgaging ability from one of their ancestors, likely the Indian Runners which are fantasic foragers. Read more about these wonderful animals on Wikipedia.
Despite a number of good qualities, these ducks are quite rare in the USA and the breed overall is considered endangered.
Catalyst on CPAN : https://metacpan.org/release/JJNAPIORK/Catalyst-Runtime-5.90050
Questhub: http://questhub.io/realm/perl/explore/latest/tag/catalyst
Git repo: git://git.shadowcat.co.uk/catagits/Catalyst-Runtime.git
| | | |
| | |
Hi Catalyst Community!
I've posted a quest list of things that are likely suspects for the next development cycle of Perl Catalyst, codenamed "Ancona".
http://questhub.io/realm/perl/explore/latest/tag/ancona
Please take a look and ponder the possible futures!
About the Ancona Duck: Ancona's are mild tempered ducks that can be great self foragers given space and tend to be decent egg layers (over 250 eggs a year not uncommon). They probably get the forgaging ability from one of their ancestors, likely the Indian Runners which are fantasic foragers. Read more about these wonderful animals on Wikipedia.
Despite a number of good qualities, these ducks are quite rare in the USA and the breed overall is considered endangered.
Catalyst on CPAN : https://metacpan.org/release/JJNAPIORK/Catalyst-Runtime-5.90050
Questhub: http://questhub.io/realm/perl/explore/latest/tag/catalyst
Git repo: git://git.shadowcat.co.uk/catagits/Catalyst-Runtime.git
| | | |
| | |
