in reply to Re^5: Understanding Catalyst
in thread Understanding Catalyst

Yes. It would either be in MyApp::Model::Dice or *much* better in a Games::Dice module that has nothing to do with MyApp and is used via model glue like Catalyst::Model::Adaptor.

I am trying to write a reply to your original post but it’s pretty long and I might not get it done.

Replies are listed 'Best First'.
Re^7: Understanding Catalyst
by Anonymous Monk on Oct 05, 2015 at 21:49 UTC

    via model glue like Catalyst::Model::Adaptor.

    I don't understand why that would be necessary ... it seems gratuitous

[reply]

      It beats the crap out of 100 undecorated function calls and use|require statements sprinked all over the place and even embedded in the templates with contorted logic to surface instead of just being in [% c.model("WhatWhat").call %] and then something impossible to repurpose, let alone trivially change, with a simple back end swap. c.uri_for() might seem gratuitous too if you’ve never grown an app that needed testing, flexible deployment, or midstream changes that could otherwise be trivial. :P

[reply]
[d/l]
[select]

        It beats the crap out of 100 undecorated function calls and ... :P

        What does that mean?

        Why would you need use/require embedded in templates?

        c.uri_for() might seem gratuitous too if you’ve never grown an app that needed testing, flexible deployment, or midstream changes that could otherwise be trivial. :P

        uri_for is one function, its not an entire new namespace whose only reason to exist is so some other name space can register a model with catalyst -- why does it need an extra class to inherit from an adaptor?

        The answer may seem dead obvious as "beats the carp" but could you elaborate?

[reply]

In Section Seekers of Perl Wisdom