Application Development using Catalyst, Moose, Plack, DBIx::Class and other Modern Perl software!

Web/Tech

01/09/2015

Today we announce that the Holland development cycle is complete. Catalyst v5.90080 is now on CPAN. The only changes from 5.90079_008 are minor documentation changes. Check it out!

If you've not been following, this release of Catalyst has major changes and improvements in UTF-8 and encoding support. Going forward Catalyst will encode to the UTF-8 standard by default. Please review the changelog, Delta and Upgrade docs carefully.

There is now also a new document that overviews UTF-8 and encoding support in Catalyst which is worth a read.

Other noteworthy changes include a new action match subroutine attribute ":Scheme()" that allows you to match your action routes based on if the incoming request meets a certain URI scheme such as HTTPS or WS. This is supported in $c->uri_for such that if you create a URI object for an action that has a Scheme we use that scheme in the URI, instead of the current request Scheme. This makes it easier to generate URIs for actions when your application has a mix of allowed Schemes (such as when part of your website is HTTPS and another part HTTP). See the advent article here for more examples.

Thanks to everyone that contributed to this release. Its been a bit of a haul to get here, but I think this change is going to help settle issues around encoding going forward.

The upcoming development cycle is codenamed "Australorp". The current proposed TODO list can be viewed and commented on here.

01/07/2015

Now that the current development cycle is starting to close (barring show stopper bugs we will make the current dev008 release stable later this week) I want to circulate the current proposed issue list for hacking during the upcoming development burn.

This is a preliminary list and will likely get pared down a bit and the scope of these things could be better defined and narrowed over time but this is as good a place to kick things off as anything else.

If you have already been testing dev006 shipped earlier this week you don't need to worry about this one since its nearly all documentation updates. This release represents updates to documention primarily around UTF8 and encoding. This is hopefully the final docs we can feel are good enough to ship with stable. In addition to information in the upgrading pod and inline API level documentation we added a new document Catalyst::UTF8 which expands and corrects the UTF8 and encoding documentation that was published during Advent 2014. If you read those, this is still worth a look since a few things have changed and this version has more info. If you didn't read it, you should really read this since it summarizes a ton of information regarding UTF8 and encoding in Catalyst. In particular if you consider yourself a Unicode kungfu master, please read that document and let me know if you think the underlying concepts are inline with best practices.

There's also more UTF8 tests and a few test corrections that was giving our colleagues using Windows some trouble. If this continues to pass CPAN testers and I don't hear of any major showstoppers from those of you testing either dev006 or dev007 we expect to ship this as 5.90080 stable on this coming Friday (09 January 2015).

Thanks to everyone that reviewed code and helped me to test this. I hope this is the best version yet of Perl Catalyst!

01/05/2015

Perl Catalyst version 5.90079_006 'Holland' has been on CPAN for a few days and appears to be stable. In addition I've been checking around and it seems most of the common views and Plugins are ok or have been updated to be good with the new changes. As a result I am planning to release stable shortly. If you are testing this development release, or have a plan to do so shortly and would like a bit more time, please shout out.

This version of Catalyst contains big fixups to UTF8 encoding, and also includes changing the default encoding to UTF8. I think in 2015 this is expected in a modern framework. Also I have found that without a definative statement on the subject from core, various extensions have tended to go their own way in solving some of these tricky encoding issues. So having this change in core is hopefully going to make it easier to keep everyone on the same page. It does qualify as a big change, which is why I will say for the last time:

"Please test this and send me your bug reports"!

I'm going to be very discouraged if I get them the week AFTER we take this code to stable. So complain now or either wait til I have time later to fix your bugs (or you can pay me to fix your bugs).

We continue to make changes around encoding and UTF8 to better support existing plugins and existing code. We also made a first stab at documentation and tried to make using encoding a bit more flexible. See the full change log:

I am encouraging people to make this a development release you bother to test since the changes to fix UTF8 support are deeper than the average release. I am targeting January 28, 2015 to make this stable so less than a month to review and get me your feedback!

12/02/2014

There's a new development release on CPAN which has a ton of fixes and changes around UTF8 and encoding. Amongst these changes are te fact UTF8 encoding is enabled by default, which is a proposed change still subject to reversing if it turns out to be too painful.

If you never bother to test development releases of Catalyst, this is the one time you really should. I expect this dev cycle to remain elongated compared to the ones in the recent past given the depth of refactoring here.

Although the bulk of the changes are around UTF8 and encoding there's a few other tweaks, including a new dispatcher mathing rule 'Scheme' that lets you match actions based on the URL scheme (for example to require an action to be HTTPS).

If you are a CPAN author that supports bits in the extended Catalyst ecosystem I recommend testing as well.

09/15/2014

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:

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.

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.

08/08/2014

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!

07/14/2014

"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:

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.

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:

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.

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:

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.

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:

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:

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.

06/09/2014

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.

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.