Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Shlomi Fish (918)

Shlomi Fish
  shlomif@iglu.org.il
http://www.shlomifish.org/
AOL IM: ShlomiFish (Add Buddy, Send Message)
Yahoo! ID: shlomif2 (Add User, Send Message)
Jabber: ShlomiFish@jabber.org

I'm a hacker of Perl, C, Shell, and occasionally other languages. Perl is my favourite language by far. I'm a member of the Israeli Perl Mongers, and contribute to and advocate open-source technologies. Technorati Profile [technorati.com]

Journal of Shlomi Fish (918)

Thursday June 09, 2005
02:14 AM

Catalyst

[ #25108 ]

After learning some Ruby on Rails from the O'Reilly-Net tutorial, I went over the Perl.com Catalyst Tutorial. Then I decided that I'll write an application in it in order to learn it better.

So I began to write it. It took me two or three days and right now I only have a record display page, an edit form and an addition form for one of the tables. Part of it is because I'm not very familiar with Class::DBI and other technologies Catalyst is making use of. Hopefully I'll become more familiar with everything as I invest more time.

Meanwhile, I discovered a misbehaviour in the Catalyst core: trailing slashes in the PATH_INFO are ignored. So /myapp/path1/ would be reported the same as /myapp/path1. This may break a lot of relative URLs. I traced the problem to a line containing split /\//, $c->req->path, which throws away components that are empty from the end. A Patch I wrote to change it to split /\//, $c->req->path, -1 was rejected after I was told some people may depend on this erroneous behaviour.

I was instructed to write a Plugin instead, which I did. A problem I encountered was that this call to split appeared right at the beginning of a much larger function. I wrote another patch, to extract a method with this, but it was rejected because they did not want to clutter the API.

Thus, Catalyst-Plugin-SanitizeUrl has to duplicate the code of the function, extract a method out of it, and then override this method. <sigh /> But it works([tm]).

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • That sounds a lot of work to get going with a framework that's supposed to be easy to use.

    I'm curious how find it compares to the more established CGI::Application [cpan.org] MVC framework.

    It's now about turn 5 years old and features over a dozen plugins. (disclaimer: I contribute to CGI::App).

    • I don't know how easy to use is Catalyst supposed to be, but it's certainly quite complex and gives one a lot of functionality. Add to that the fact that I did not yet read all of the documentation, and it may indicate why it takes me so much time to get the hang of it.

      I have worked with CGI::Application in the past. It may be a little stretch calling CGI::App a true MVC framework, especially considering the fact that it's not really RDBMS-aware. In any case, CGI::App is nice and all, but Catalyst gives

      • It may be a little stretch calling CGI::App a true MVC framework, especially considering the fact that it's not really RDBMS-aware.

        I'm not sure when RDBMS became part of the MVC definition, but it's very easy to add database integration:

        package My::Class;
        use base CGI::Application';
        use CGI::Application::Plugin::DBI (qw/dbh dbh_config/);

        If you want to use Class::DBI, you can use it normally. CGI::App doesn't need to get the middle.

        In any case, CGI::App is nice and all, but Catalyst gives you mu

        • Well, Catalyst implements caching very well. It has a built-in way to map URLs to methods and parameters, and it also has a much larger number of Plugins than CGI::App has. And there's still a lot to be done in it.
  • For what it's worth, I'm on your side on this. URLs ending in a slash and those that don't, are not the same, neither to web servers, or to browsers. A framework that makes it impossible to distinguish between the two, is buggy, IMO. Hiding behind backward compatibility to leave it like this, is wrongheaded. In my eyes.

    Furthermore, I think it's they who should provide a plugin to get back the old, buggy behaviour, after it's been fixed, for those people (if they even exist) silly enough to depend on these

    • Thanks for the support. I believe the solution of the Catalyst guys was that I should always use absolute URLs (such starting with a "/"). I personally don't buy that it's a good solution.