FAQ
Given I appear to have volunteered to talk up Catalyst at the London Web
Frameworks Night (http://blog.unixdaemon.net/cgi-bin/blosxom.pl/2005/10/27),
I'd like to know what features are the "killer" ones for our users and why?

--
Matt S Trout Specialists in Perl consulting, web development, and
Technical Director UNIX/Linux systems architecture and automation. Mail
Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information

+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +

Search Discussions

  • Sebastian Riedel at Oct 29, 2005 at 10:57 pm

    Am 29.10.2005 um 21:13 schrieb Matt S Trout:

    Given I appear to have volunteered to talk up Catalyst at the
    London Web
    Frameworks Night (http://blog.unixdaemon.net/cgi-bin/blosxom.pl/
    2005/10/27),
    I'd like to know what features are the "killer" ones for our users
    and why?
    First, thanks for taking the task!


    And some things i like.

    1. The method to uri mapping is just awesome. :)
    sub foo : Path('/index.html') {}
    sub foo : Global {}
    sub foo : Local {}
    sub foo : Regex('^(.*)\.html$') {}

    2. The engine layer, your Cat apps work exactly the same on all
    platforms (cgi, fcgi, mod_perl1/1.99/2)

    3. The plugin system, you can change/extend everything with plugins.

    4. The directory structure, your Cat app is a usual CPAN module and
    is installable as such.

    5. The easy CPAN integration, wrapping existing modules into
    components and plugins is usually just a few lines of code.

    6. The freedom of choice, there are alternatives for all components
    (TT, Mason, DBIC, Tangram...), you can even use multiple in a single
    app.

    7. The developer features, built in test-server, verbose logs, debug
    screen...

    8. The future, Catalyst is the perfect platform for next generation
    frameworks (continuations, generic base classes...).


    P.S.: You should make clear that we are no Rails clone, try to show
    them their weaknesses instead (Rails for example: no engine
    independent abstraction layer, no CPAN, no alternatives, no unicode,
    no I18n, slow, no multiple inheritance, no method meta data like our
    attributes, smaller userbase, less commercial support...). :)


    --
    sebastian
  • Adam Jacob at Oct 29, 2005 at 11:04 pm

    On Oct 29, 2005, at 2:04 PM, Sebastian Riedel wrote:
    3. The plugin system, you can change/extend everything with plugins.
    I have to say, this is one of the best things I've found while doing
    Cat apps. I needed, for example, to have Log::Log4perl support.
    Getting that done was really simple; just build a small wrapper, add
    it to the plugin chain, and viola.

    Adam
  • Sebastian Riedel at Oct 29, 2005 at 11:09 pm

    Am 29.10.2005 um 23:04 schrieb Sebastian Riedel:
    P.S.: You should make clear that we are no Rails clone, try to show
    them their weaknesses instead (Rails for example: no engine
    independent abstraction layer, no CPAN, no alternatives, no
    unicode, no I18n, slow, no multiple inheritance, no method meta
    data like our attributes, smaller userbase, less commercial
    support...). :)
    "smaller userbase" is a bit unclear.
    I meant Perl vs. Ruby, Rails itself has more users than Catalyst.


    --
    sebastian
  • Pedro Melo at Oct 30, 2005 at 12:14 am
    Hi,
    On Oct 29, 2005, at 10:04 PM, Sebastian Riedel wrote:

    Am 29.10.2005 um 21:13 schrieb Matt S Trout:
    Given I appear to have volunteered to talk up Catalyst at the London
    Web
    Frameworks Night
    (http://blog.unixdaemon.net/cgi-bin/blosxom.pl/2005/10/27),
    I'd like to know what features are the "killer" ones for our users
    and why?
    1. The method to uri mapping is just awesome. :)
    sub foo : Path('/index.html') {}
    sub foo : Global {}
    sub foo : Local {}
    sub foo : Regex('^(.*)\.html$') {}
    this is one of the best things. It makes a very clean code base with
    enforced separation of actions per method.
    3. The plugin system, you can change/extend everything with plugins.
    plugins are also very nice, and very light. Promotes reuse with other
    CPAN modules, because its very easy to wrap a CPAN module in a plugin.
    5. The easy CPAN integration, wrapping existing modules into
    components and plugins is usually just a few lines of code.
    yep, see previous.
    7. The developer features, built in test-server, verbose logs, debug
    screen...
    The debug screen, with the DefaultEnd plugin and the dump_info
    parameter are excellent time-savers during development.
    P.S.: You should make clear that we are no Rails clone, try to show
    them their weaknesses instead (Rails for example: no engine
    independent abstraction layer, no CPAN, no alternatives, no unicode,
    no I18n, slow, no multiple inheritance, no method meta data like our
    attributes, smaller userbase, less commercial support...). :)
    If Catalyst is no RoR clone, don't mention RoR: use your time to talk
    about Catalyst.

    Best regards,
    --
    Pedro Melo
    JID: melo@simplicidade.org, open to all (unless you use Google Talk)
    ** Federation: just say no **
  • Sam Vilain at Oct 30, 2005 at 9:57 pm

    On Sat, 2005-10-29 at 23:14 +0100, Pedro Melo wrote:
    1. The method to uri mapping is just awesome. :)
    sub foo : Path('/index.html') {}
    sub foo : Global {}
    sub foo : Local {}
    sub foo : Regex('^(.*)\.html$') {}
    this is one of the best things. It makes a very clean code base with
    enforced separation of actions per method.
    It also could make finding entry points for a given path very hard in an
    application which is "somebody else's".

    How is resolving this typically solved on a Catalyst code base? Do you
    compile the app and ask it for its URI mapping, or simply "try to keep
    it under control" ?

    In my own URI to handler mapper (on CPAN as PSA::Cache), I use a
    convention that mirrors CGI in style - URIs simply get resolved to
    relative pathnames, with path_info and "index" feature equivalents. In
    this instance, I preferred convention over flexibility. It did have its
    drawbacks; for instance moving paths around was often a PITA. But it
    sure was simple to explain and understand.

    Sam.
  • Robert Sedlacek at Oct 30, 2005 at 10:26 pm
    Sam Vilain said:
    It also could make finding entry points for a given path very hard in an
    application which is "somebody else's".

    How is resolving this typically solved on a Catalyst code base? Do you
    compile the app and ask it for its URI mapping, or simply "try to keep
    it under control" ?
    I'd suggest starting the debug-server and the application in debug mode.
    The output would show you the private actions.

    p
  • Sebastian Riedel at Oct 30, 2005 at 10:34 pm

    Am 30.10.2005 um 22:02 schrieb Sam Vilain:
    On Sat, 2005-10-29 at 23:14 +0100, Pedro Melo wrote:

    1. The method to uri mapping is just awesome. :)
    sub foo : Path('/index.html') {}
    sub foo : Global {}
    sub foo : Local {}
    sub foo : Regex('^(.*)\.html$') {}
    this is one of the best things. It makes a very clean code base with
    enforced separation of actions per method.
    It also could make finding entry points for a given path very hard
    in an
    application which is "somebody else's".

    How is resolving this typically solved on a Catalyst code base? Do
    you
    compile the app and ask it for its URI mapping, or simply "try to keep
    it under control" ?

    In my own URI to handler mapper (on CPAN as PSA::Cache), I use a
    convention that mirrors CGI in style - URIs simply get resolved to
    relative pathnames, with path_info and "index" feature
    equivalents. In
    this instance, I preferred convention over flexibility. It did
    have its
    drawbacks; for instance moving paths around was often a PITA. But it
    sure was simple to explain and understand.
    The log output of a simple myapp example should explain it. :)


    odyssey:~/MyApp sri$ script/myapp_server.pl
    [Sun Oct 30 22:39:32 2005] [catalyst] [debug] Debug messages enabled
    [Sun Oct 30 22:39:32 2005] [catalyst] [debug] Loaded plugins:
    .-----------------------------------------------------------------------
    ------.

    Catalyst::Plugin::Static::Simple
    '-----------------------------------------------------------------------
    ------'

    [Sun Oct 30 22:39:32 2005] [catalyst] [debug] Loaded dispatcher
    "Catalyst::Dispatcher"
    [Sun Oct 30 22:39:32 2005] [catalyst] [debug] Loaded engine
    "Catalyst::Engine::HTTP"
    [Sun Oct 30 22:39:32 2005] [catalyst] [debug] Found home "/Users/sri/
    MyApp"
    [Sun Oct 30 22:39:32 2005] [catalyst] [debug] Loaded components:
    .-----------------------------------------------------------------------
    ------.

    MyApp::C::Foo
    '-----------------------------------------------------------------------
    ------'

    [Sun Oct 30 22:39:32 2005] [catalyst] [debug] Loaded Private actions:
    .--------------------------------------
    +---------------------------------------.
    Private |
    Class |
    =-------------------------------------
    +--------------------------------------=|
    /default |
    MyApp |
    /foo/bar |
    MyApp::C::Foo |
    '--------------------------------------
    +---------------------------------------'
    [Sun Oct 30 22:39:32 2005] [catalyst] [debug] Loaded Path actions:
    .--------------------------------------
    +---------------------------------------.
    Path |
    Private |
    =-------------------------------------
    +--------------------------------------=|
    /foo/bar | /foo/
    bar |
    '--------------------------------------
    +---------------------------------------'
    [Sun Oct 30 22:39:32 2005] [catalyst] [info] MyApp powered by
    Catalyst 5.49_02
    You can connect to your server at http://odyssey.local:3000


    --
    sebastian
  • Thomas L. Shinnick at Oct 30, 2005 at 10:45 pm

    At 15:02 10/30/2005, Sam Vilain wrote:
    On Sat, 2005-10-29 at 23:14 +0100, Pedro Melo wrote:
    1. The method to uri mapping is just awesome. :)
    sub foo : Path('/index.html') {}
    sub foo : Global {}
    sub foo : Local {}
    sub foo : Regex('^(.*)\.html$') {}
    this is one of the best things. It makes a very clean code base with
    enforced separation of actions per method.
    It also could make finding entry points for a given path very hard in an
    application which is "somebody else's".

    How is resolving this typically solved on a Catalyst code base? Do you
    compile the app and ask it for its URI mapping, or simply "try to keep
    it under control" ?
    When the debug option is enabled Catalyst displays all the information you need in the initial display. The initial debug display sections are:
    [Sun...2005] [catalyst] [debug] Loaded dispatcher "Catalyst::Dispatcher"
    [Sun...2005] [catalyst] [debug] Loaded engine "Catalyst::Engine::HTTP"
    [Sun...2005] [catalyst] [debug] Found home "C:\Archive\Mine\Perl\catalyst1\Widget\trunk"
    [Sun...2005] [catalyst] [debug] Loaded tables "widget_sessions wgprogress wgscaliases wgscids wguserroles wgusers wgusersroles wgwidgets"
    [Sun...2005] [catalyst] [debug] Loaded components: ....
    [Sun...2005] [catalyst] [debug] Loaded private actions:
    [Sun...2005] [catalyst] [debug] Loaded public actions:

    The "public actions" table will show you the possible URL targets:
    [Sun...2005] [catalyst] [debug] Loaded public actions:
    .----------------------------------+-----------------------------------.
    Public | Private |
    =---------------------------------+----------------------------------=|
    /admin/list | /admin/list |
    /admin/user/add | /admin/user/add |
    /admin/user/delete | /admin/user/delete |
    /admin/user/do_add | /admin/user/do_add |
    : : : : : : :
    /login | /login/login |
    /logout | /login/logout |
    : : : : : : :
    /user/dataupld/suggest | /user/dataupld/suggest |
    '----------------------------------+-----------------------------------'

    You can cross-reference the private targets with implementing components by using the prior listing:

    [Sun...2005] [catalyst] [debug] Loaded private actions:
    .----------------------------------+-----------------------------------.
    Private | Class |
    =---------------------------------+----------------------------------=|
    /begin | Widget |
    /default | Widget |
    /end | Widget |
    : : : : : : :
    /admin/default | Widget::C::Admin |
    /admin/list | Widget::C::Admin |
    /admin/end | Widget::C::Admin |
    /admin/user/add | Widget::C::Admin::User |
    /admin/user/default | Widget::C::Admin::User |
    /admin/user/end | Widget::C::Admin::User |
    /admin/user/delete | Widget::C::Admin::User |
    /admin/user/do_add | Widget::C::Admin::User |
    : : : : : : :
    /user/dataupld/suggest | Widget::C::User::DataUpld |
    : : : : : : :
    /login/logout | Widget::C::Login |
    /login/default | Widget::C::Login |
    /login/login | Widget::C::Login |
    /login/end | Widget::C::Login |
    '----------------------------------+-----------------------------------'

    So it is fairly easy to determine that URLs like "/user/dataupld/suggest" will be handled by component Widget::C::User::DataUpld. That "/login" will be handled in Widget::C::Login. Also that unrecognized URLs beginning "/admin/xxxx" will be handled by Widget::C::Admin.

    Just turn on the -Debug option to see Catalyst tell you what it knows.
    In my own URI to handler mapper (on CPAN as PSA::Cache), I use a
    convention that mirrors CGI in style - URIs simply get resolved to
    relative pathnames, with path_info and "index" feature equivalents. In
    this instance, I preferred convention over flexibility. It did have its
    drawbacks; for instance moving paths around was often a PITA. But it
    sure was simple to explain and understand.

    Sam.
  • Sebastian Riedel at Oct 30, 2005 at 10:38 pm

    Am 30.10.2005 um 00:14 schrieb Pedro Melo:
    P.S.: You should make clear that we are no Rails clone, try to
    show them their weaknesses instead (Rails for example: no engine
    independent abstraction layer, no CPAN, no alternatives, no
    unicode, no I18n, slow, no multiple inheritance, no method meta
    data like our attributes, smaller userbase, less commercial
    support...). :)
    If Catalyst is no RoR clone, don't mention RoR: use your time to
    talk about Catalyst.
    Right, but this is a Catalyst vs. Rails vs. Django evening, so the
    topic will come up anyway...

    --
    sebastian
  • David Storrs at Oct 30, 2005 at 11:13 pm

    On Oct 29, 2005, at 6:14 PM, Pedro Melo wrote:
    On Oct 29, 2005, at 10:04 PM, Sebastian Riedel wrote:
    Am 29.10.2005 um 21:13 schrieb Matt S Trout:
    Given I appear to have volunteered to talk up Catalyst at the
    London Web
    Frameworks Night (http://blog.unixdaemon.net/cgi-bin/blosxom.pl/
    2005/10/27),
    I'd like to know what features are the "killer" ones for our
    users and why?
    [...]
    P.S.: You should make clear that we are no Rails clone, try to
    show them their weaknesses instead (Rails for example: no engine
    independent abstraction layer, no CPAN, no alternatives, no
    unicode, no I18n, slow, no multiple inheritance, no method meta
    data like our attributes, smaller userbase, less commercial
    support...). :)
    If Catalyst is no RoR clone, don't mention RoR: use your time to
    talk about Catalyst.
    I agree with Pedro: don't spend time pointing at the weaknesses of
    others. Instead, talk about our strengths. Also, talk about our
    (perceived)? weaknesses and how we are addressing them. Some
    suggestions:

    Weakness:
    ---------
    * Our documentation is inadequate

    ** We have set up a wiki which is growing slowly but steadily.
    ** We have an extremely active IRC channel with knowledgeable
    people around pretty much 24/7. Most of them are willing & eager to
    help.
    ** We have rewritten the default screen to provide more
    information and pointers to valuable beginner material.
    ** We welcome patches and new documents.

    Perceived Weakness:
    -------------------
    * Our code is based off of NEXT.pm instead of <preferred method of
    inheritance>

    ** Summarize any one of the relevant threads from the list. Do
    it non-confrontationally in terms of "We believe it's better this way
    because...."


    If you can't think of any weaknesses, take a list at the TODO list.

    --Dks
  • John Beppu at Oct 31, 2005 at 3:55 pm

    And some things i like.

    1. The method to uri mapping is just awesome. :)
    sub foo : Path('/index.html') {}
    sub foo : Global {}
    sub foo : Local {}
    sub foo : Regex('^(.*)\.html$') {}

    2. The engine layer, your Cat apps work exactly the same on all
    platforms (cgi, fcgi, mod_perl1/1.99/2)

    3. The plugin system, you can change/extend everything with plugins.

    4. The directory structure, your Cat app is a usual CPAN module and
    is installable as such.

    5. The easy CPAN integration, wrapping existing modules into
    components and plugins is usually just a few lines of code.

    6. The freedom of choice, there are alternatives for all components
    (TT, Mason, DBIC, Tangram...), you can even use multiple in a single
    app.

    7. The developer features, built in test-server, verbose logs, debug
    screen...

    8. The future, Catalyst is the perfect platform for next generation
    frameworks (continuations, generic base classes...).


    sri covered a lot. For me,
    1, 2, 4, 7 and 8
    have been the most helpful.

    Comments:

    1. on using attributes for handler-to-uri mapping: This is one of the most
    clever things I've ever seen done in perl, and it makes me wish I knew more
    about attributes so that I could apply it elsewhere in my own work.

    2. on engine independence: At work, I'm the one who usually sets up the more
    junior programmers (because a lot of them are new to Unix and it would take
    them a long time to set up Apache by themselves). With that said, allowing
    them to run a site using the built-in server has been a god-send. Also, our
    technical director wants to transition to Apache2, and it feels good knowing
    that we won't have to recode anything that was done with Catalyst.

    4. on the CPAN-friendly directory structure: I'm a big fan of the
    CPAN-styled layout, and I'm happy that I can make a distribution out of a
    whole site. It certainly makes deployment easier.

    7. on the developer-friendly features: The built-in test server, verbose
    error_log, and debug screen are all quite helpful. Sometimes, I wish the
    output were a bit less verbose, but that's not a big deal.

    8. on the use of advanced programming techniques: I've always been a fan of
    sophisticated programming. To me, being able to write clean, concise, and
    powerful code is a reward in itself.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.rawmode.org/pipermail/catalyst/attachments/20051031/471a8d32/attachment.htm
  • Kenny Gatdula at Oct 31, 2005 at 2:48 am

    Matt S Trout wrote:
    Given I appear to have volunteered to talk up Catalyst at the London Web
    Frameworks Night (http://blog.unixdaemon.net/cgi-bin/blosxom.pl/2005/10/27),
    I'd like to know what features are the "killer" ones for our users and why?
    Built-in JSAN support. :)

    Kenny
  • Kevin C. Thomas at Oct 31, 2005 at 1:10 pm
    I'm a relative perl newbie ( much less so than ruby ), but the feature that
    is most important to me is that Catalyst is perl and perl will run on my
    current web host and I occasionally use perl in my day-job work. It'd be
    interesting to know the relative sizes of the perl / ruby development
    camps.A second feature important to me is the ability to swap out engines
    that ruby doesn't seem to have.

    -----Original Message-----
    From: catalyst-bounces@lists.rawmode.org
    On Behalf Of Kenny Gatdula
    Sent: Sunday, October 30, 2005 8:53 PM
    To: The elegant MVC web framework
    Subject: SPAM-LOW: Re: [Catalyst] So, what things make Catalyst cool for
    you?

    Matt S Trout wrote:
    Given I appear to have volunteered to talk up Catalyst at the London Web
    Frameworks Night
    (http://blog.unixdaemon.net/cgi-bin/blosxom.pl/2005/10/27),
    I'd like to know what features are the "killer" ones for our users and
    why?
    >
    Built-in JSAN support. :)

    Kenny

    _______________________________________________
    Catalyst mailing list
    Catalyst@lists.rawmode.org
    http://lists.rawmode.org/mailman/listinfo/catalyst


    --
    No virus found in this incoming message.
    Checked by AVG Free Edition.
    Version: 7.1.361 / Virus Database: 267.12.5/150 - Release Date: 10/27/2005

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedOct 29, '05 at 8:59p
activeOct 31, '05 at 3:55p
posts14
users11
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2021 Grokbase