24 posts tagged “catalyst”

NB: This is my first post in the EPO Iron Man challenge. (Warning: contains some expletives)

First and foremost, the long awaited Catalyst 5.8 is out! My mind-share has primarily been with the 5.7x series so I've been pretty much out of the loop on everything that's going on. Luckily enough, everything is basically backwards compatible (less any necessary module upgrades).

Besides the usual round of bug fixes, this release is built on top of Moose. I'm a big fan of Moose and the ease with which it lets me code, so I'm very excited to see this feature. Be sure to check the Changelog for all of the details.

As far as my personal projects go, I've finally been able to deprecate two of my oldest modules (Image::ANSI and Image::XBin) with the latest release of Image::TextMode. This release now mirrors all features provided by the two before it (and then some). It can now write each format (not 100% complete, but release-worthy) -- I've even included a little bit of naive RLE compression.

Personal projects let me explore some new/different technologies which may not fit in do my daily $work. One of those would be Moose, as mentioned above (which is now part of our standard "toolkit"). Another would be XS. Writing Image::TextMode::Reader::ANSI::XS was very eye opening as far as hooking Perl and C code together and illuminating the Perl internals for me.

Recently, I've been in tune with adding new QA tools to my repertoire, such as: Benchmark (high time I learned more about it), Perl::Critic (again, about time) and Devel::NYTProf.

If I'm going to keep up with this "Iron Man Challenge," then maybe I will save my favorite QA tools for their own post. Stay tuned!

Like i said back in July, Catalyst 5.71000 would happen before the moose-ified 5.80 gets shipped. That day is here. Here's the basics on what's new since 5.7015:

   
• Relatively chained actions   
• PathPrefix (I only mentioned that, oh, 2 years ago :)   
• $c->go and $c->visit (they do a full dispatch to the action; this should kill the SubRequest plugin)   
• Refactored component resolution (which is something else I worked on)   
• Documentation improvements   
• Misc bug fixes
  

Enjoy!

One of the things you'll see in the changelog for the next stable release of Catalyst, is a reworked component resolution system. By "component resolution" i mean, fetching components from view()/views(), model()/models(), controller()/controllers() and component().

Back in May I posted a message to the Catalyst-dev list describing some issues with the way it was currently working. Although I painted a slightly convoluted picture of doom and gloom -- it turns out that all is not lost; you were probably relying on an "undefined" behavior to begin with (kind of like assuming "keys %hash" will return things in a particular order).

For example, consider "MyApp" with two views: "Foo" and "Bar." Now, when you call "$c->view()" (i.e. with no arguments) what gets returned? Well, it depends. :) If you have none of the appropriate config (default_view) or stash variables (current_view, current_view_instance) set, then it's pretty much random.

If you write a test for the above, and see that "MyApp::View::Bar" is returned -- don't count on that test working in 5.7100 (the message I posted to the list has the technical details as to why). Though the test *may* continue to work, the above scenario will throw a pretty large warning:

Calling $c->view() will return a random view unless you specify one of:
* $c->config->{default_view} # the name of the default view to use
* $c->stash->{current_view} # the name of the view to use for this request
* $c->stash->{current_view_instance} # the instance of the view to use for this request
NB: in version 5.80, the "random" behavior will not work at all.

(FYI, if your application only has one view, calling "$c->view()" is considered "acceptable" and will spare you the warnings.)

A similar warning is thrown for $c->model(). $c->controller() with no arguments will continue to return the controller for the dispatched action. $c->component (sans args) will also stay the same, returning a sorted list of all component names.

Another issue I discovered while re-working the code was a failed reliance on the "regex" fallback.

Consider another "MyApp" with two views "Foo::Bar" and "Foo::Baz". What does "$c->view('Foo')" return? We've maintained backwards compatibility on this one -- it will return all matching views (order unknown). It is important to note that this returns an array, so list context is important. We've added a warning for this scenario as well:

Relying on the regexp fallback behavior for component resolution is unreliable and unsafe.
If you really want to search, pass in a regexp as the argument.

As noted above, if you truly were just searching for views, pass it a regex ("$c->view(qr{Foo})") and it will act as expected.

So, if you think you might be affected by these particular issues, test out the dev release! Don't say I didn't warn you. :)

(Crossposted to the Catalyst-dev list)

We're putting out one final development release before we go full bore
with 5.7100.

NB: It is IMPERATIVE that you TEST this release against YOUR code. Quoth
mst: "If you do not test now any bugs we ship with are your fault!" --
so, there you have it :)

Also, we've reworked the authors list to be much like DBIx::Class; in
one spot (Catalyst.pm) with each person's IRC nick, name, and email. In
you can fill in any of the blanks, fire off an email or catch us in
#catalyst-dev and well gladly fix it up.

Whilst the release is making its way to CPAN, you can grab it from here:

http://dev.thefeed.no/stuff/Catalyst-Runtime-5.7099_02.tar.gz

The Changes since the last stable release include:

5.7099_02 2008-07-16 19:10:00
        - Added PathPrefix attribute
        - Removed Catalyst::Build; we've long since moved to
Module::Install
        - Updated Catalyst::Test docs to mention the use of HTTP::Request
          objects (Rafael Kitover)

5.7099_01 2008-06-25 22:36:00
        - Refactored component resolution (component(), models(),
model(), et al). We now
          throw warnings for two reasons:
          1) model() or view() was called with no arguments, and two
results are returned
             -- set default_(model|view), current_(model|view) or
current_(model|view)_instance
             instead
          2) you call a component resolution method with a string, and
it resorts to a regexp
             fallback wherein a result is returned -- if you really
want to search, call the
             method with a regex as the argument
        - remove 0-length query string components so warnings aren't
thrown (RT #36428)
        - Update HTTP::Body dep so that the uploadtmp config value will
work (RT #22540)
        - Fix for LocalRegex when used in the Root controller
        - Get some of the optional_* tests working from dirs with
spaces (RT #26455)
        - Fix Catalyst::Utils::home() when application .pm is in the
current dir (RT #34437)
        - Added the ability to remove parameters in req->uri_with() by
passing in
          an undef value (RT #34782)
        - Added $c->go, to do an internal redispatch to another action,
while retaining the
          contents of the stash

We're approaching the two-year anniversary of the first release in the 5.7x series of the Catalyst framework. I'm really proud of how 5.7x has gone -- it has given the project some much needed stability that was missing in the early goings. It still amuses me to look back at the changelog to watch it go from version 3.X (which is basically "Catalyst 1.0") to 5.X in the span of about two and a half months.

Although development was obviously very fast-paced then, with 14 releases since 5.7000 I wouldn't say we've stalled. Naturally, the bulk of the changes since then have been bug fixes. We've also increased the test suite from 1416 tests to 1805 (the old test suite actually ran most tests twice by default, but, by setting CAT_BENCH_ITERS=1, you will see the "1416" result).

A 5.71 dev release (5.7099_01) was recently shipped which includes a new method: go(). As marcus describes it, it "works like an internal redispatch to another action, while retaining the stash intact." I believe one more dev release will happen as I've recently checked in the long lost PathPrefix attribute.

5.71xx will be more of a short-lived series of releases to act as a buffer between 5.70XX and 5.8000. 5.8000 being the Moose conversion (see this interview for more information).

Catalyst 5.7014 is out the door. Hopefully that will stop the flood of questions about a "strange uri_for() behavior." With that done, I've taken out 5 more RT tickets.

Two extremely old wishlist items were rejected (RT #26758, RT #24132). This is basically due to the fact that they were over a year old, and really should be talked about on the dev list if they are still inclined to have them resolved.

A couple others required that I cook up a test or two to ensure the patch was applying was satisfactory (naturally, we would always hope to have a test submitted along side the patch): RT #26455, RT #34437.

The last ticket seems to have been related to a regression in 5.7013, as the ticket author claims the latest release fixed the issue. Closed! (RT #35994)

I've put the 5-a-day thing away for a bit to focus on other things. Firstly it was trying to get a new release of Catalyst-Runtime out the door (5.7013 hit CPAN on the 17th). One of the last bits preventing that release was some back-compat methods for Catalyst::Stats so it could mimic Tree::Simple behavior, which is what $c->stats() used to return.

Unfortunately, this release introduced two regressions, now fixed in svn:

1) "sub foo : Path {}" in the root controller didn't work.

This was as a result of my attempt to allow Path(0) to match properly. A simple 1-line fix resolved this problem. This bug also prevents some components' tests from working successfully (so far Catalyst-Model-Adaptor and Catalyst-Plugin-Unicode) as they used this idiom in their test apps.

2) invalid namespace for relative arguments to uri_for from an action that was run from a $c->forward() command.

Since there are a few conditions to satisfy before this bug appears I'm not too suprised it snuck in to the release. Peter Karman provided a much needed test case and the simple fix (remove "local $c->{namespace} = $self->namespace") which i've included in the 5.70 trunk.

I hope we can get 5.7014 out the door relatively swiftly.

I've also fixed up a couple of Catalyst::Plugin::Authentication RT tickets. Both were simple pod fixes: RT #36062, RT #36063

Note to self...

If, in my Catalyst app, I have a template that includes unicode text, then not only should I save the file as UTF-8, but I should also include a Byte Order Mark (BOM). If I don't I'll end up seeing what looks like double encoded bytes -- and that annoys the hell out of me.

Currently, your "MyApp.pm" file is both your application class and your context class (NB: this is expected to change in 5.8000). We've been slowing suggesting that people move things out of th context/app class so as not to pollute it with an abundance of mehods which may occasionally have unwanted consequences -- for example "login : Global {}" conflicting with the Authentication plugin's login() method.

This tip is broken into two parts:

1. It's been said time and time again (c.f. this and this [phaylon++]), not everthing has to be a plugin! If the sum total of your plugin is this:
   
   

   package Catalyst::Plugin::Foo;

   use Foo;

   sub foo {
       my( $c, @rest ) = @_;
       return Foo->new( @rest );
   }
   

   You should reconsider. Either use the module directly, or make a controller base class. That should handle most cases.
2. Be careful what you import into MyApp.pm! Some modules will export methods (and other symbols) by default, and sometimes you'll do it manually. Consider explicitly importing nothing:
   
   before:
   
   

   package MyApp;

   use Digest::MD5 qw(md5_hex); # MyApp now has the md5_hex method

   sub foo {
       # ...
       return md5_hex( $string );
   }
   

   after:
   
   

   package MyApp;

   use Digest::MD5 (); # no imports

   sub foo {
       # ...
       return Digest::MD5::md5_hex( $string );
   }
   

   If you want a quick-n-easy cleanup, try namespace::clean.
   

Since I've push a new stable release of WWW::OpenSearch, I was able to push some new modules that depended on it. In particular WebService::Lucene -- a perl client to the lucene-ws java servlet. We've been using the module in production for just under a year with great success.

I've also pushed a simple Catalyst model to CPAN as well. However, once I give DBIx::Class::Indexed + Indexer::* the ability to search, then that model will have very little practical usage for us.