FAQ
Hi,

As a few may remember I brought this up a while ago and after working
with this for a while I just want to make sure we are really
understanding and using this correctly...

Postulates:
1) Ideally all the business code should be abstracted into models and
more ideally these models should be classes that are independent from
Catalyst. We shall call these business model classes to differentiate
them from Catalyst Model classes.
2) The Catalyst model as such (script/xx_create.pl model yyy) should
be a thin wrapper to the business model classes from postulate 1.
3) Catalyst Models may be classes or instances.

Design Patterns:
1) If the Catalyst model will be a class, the pattern is very simple:
The catalyst model class uses the business object class just like any
other library. As I understand it, the controller code would have to
invoke new() on the model class to create a new instance of the class
that will die with the request (will lose scope from the controller
method that created it).
2) If the Catalyst model will be an instance, the design pattern is a
per-request object factory. The fat code should be kept in the
instance class, and the ACCEPT_CONTEXT method should be used to
instantiate a leaner class and return _that_ to the controller. The
idea of an instance, is that most of the heavy duty code remain
instantiated and the code is purely functional.

Assumptions and Questions
1) Is the assumption that in the first design pattern the controller
has to call new() correct? (I have always worked with the second
pattern, so I don't know for sure).
2) For Catalyst instance models, the request classes should not
contain any heavy duty code. So forcibly the request class needs a
reference to the parent model class (the factory). This is so the
request class is able to use the methods of the factory class. Is this
assumption correct?
3) It is written somewhere (I couldn't find it before writing this but
I know is in the POD somewhere) that it is not a good idea to pass the
complete $c reference to the per-request object, but rather only the
necessary pieces of $c. What are the implications of passing the
complete $c ?

Any other comments greatly appreciated. I think this could make an
interesting article for the Wiki so I want to get all the real experts
opinions on this before I attempt to create it.

Thanks,

--
Alejandro Imass

Search Discussions

  • Octavian Rasnita at May 18, 2011 at 5:42 am
    From: "Alejandro Imass" <alejandro.imass@gmail.com>
    3) It is written somewhere (I couldn't find it before writing this but
    I know is in the POD somewhere) that it is not a good idea to pass the
    complete $c reference to the per-request object, but rather only the
    necessary pieces of $c. What are the implications of passing the
    complete $c ?


    If you pass the context $c to the business model, and the business model
    would need to access the attributes and methods offered by $c, then you
    won't be able to use that business model outside of Catalyst because you
    won't have the context variable available.

    Octavian
  • Alejandro Imass at May 18, 2011 at 1:05 pm

    On Wed, May 18, 2011 at 1:42 AM, Octavian Rasnita wrote:
    From: "Alejandro Imass" <alejandro.imass@gmail.com>
    3) It is written somewhere (I couldn't find it before writing this but
    I know is in the POD somewhere) that it is not a good idea to pass the
    complete $c reference to the per-request object, but rather only the
    necessary pieces of $c. What are the implications of passing the
    complete $c ?


    If you pass the context $c to the business model, and the business model
    would need to access the attributes and methods offered by $c, then you
    won't be able to use that business model outside of Catalyst because you
    won't have the context variable available.

    Octavian
    Thanks for your prompt reply. Absolutely agree. For example, even
    stuff like loggers, etc. should be kept independent of Catalyst, that
    is clear to me. But my question is specific to the Catalyst Model
    "Instance" (pattern #2 in my OP). That is, the the model instance is a
    factory that spawns smaller per-request objects vis the ACCEPT_CONTEXT
    method. This is all catalyst, since in this pattern it must be assumed
    that the business model classes are instantiated as long-living
    objects in the factory class, probably as attributes (Refs) of the
    Catalyst Model Instance.

    In other words, the business code should be instantiated by the
    factory class, for example: a business model class would be
    instantiated as an attribute (type Ref) of the Catalyst Model Instance
    so the business logic is loaded only once, and does not have to be
    loaded per every request and then thrown away. This also means two
    things which is what I would like to verify with you here:

    1) The per-request objects (the ones spawned by the Catalyst Model
    Instance in ACCEPT_CONTEXT) forcibly need a reference to the factory
    class so they can access the business model objects that were
    instantiated upon start-up.

    2) The business model classes need to receive all the information
    needed, that-is the data structures of the per-request information
    that live in the smaller per-instance objects. This pattern allows you
    to pre-load all your business logic in the factory class and
    effectively de-couple the business logic from Catalyst.

    Anyway, that's whay I see as the whole point of Catalyst Instances,
    mean that you can pre-load as much of the business code in RAM and
    only spwan very small clases per-request that are basically all data:
    that is the methods of these per-request objects should actually be
    calling methods in the pre-instantiated code in the factory class (the
    Catalyst Model instance).

    This makes the Model Instance a wrapper of business class and itself
    can be modelled in two ways:

    1) The methods of the factory are wrappers of private business class objects.
    2) The business classes are references modeled as attributes of the
    factory class and invoked directly by the per-request objects.

    I just want to make sure these suggested patterns are not doing
    something horribly stupid that would make the app useless in a
    multi-threaded env for example (i.e. *NIX mod_perl + mod_worker).

    Maybe I should craft up some sample code of the three patterns identified:

    1) Catalyst Models Classes: that completely instantiate per request.
    2) Catalyst Model Instances: with wrapper methods
    3) Catalyst Model Instances: with wrapper attributes

    In both 2 and 3, business objects as such are instantiated when the
    Catalyst Model is instantiated. The difference is how to expose the
    business objects to the per-request objects spawned by ACCEPT_CONTEXT.

    Why am I doing all this? Because if you look at the books that
    currently exist about Catalyst, the POD and the Wiki, honestly there
    are no simple and down to earth explanations on Catalyst models, just
    a lot of blurb on "what" are the best practices but no so much "how"
    they should be accomplished and with clear down to earth examples for
    the mere mortal.

    I'm willing to do the work but first I want to make sure my conceptual
    framework is correct. I think there should be some clear code examples
    with the different patterns to actually achieve these best practices.

    Best,

    --
    Alejandro
  • Benjamin Hitz at May 19, 2011 at 11:06 pm

    Maybe I should craft up some sample code of the three patterns identified:

    1) Catalyst Models Classes: that completely instantiate per request.
    2) Catalyst Model Instances: with wrapper methods
    3) Catalyst Model Instances: with wrapper attributes
    Would like to see that. Some of us don't follow all this abstract computer science jargon that well.

    Also - can you comment on the following:

    WARNING WARNING WARNING

    Using this module is somewhat of a hack. Changing the state of your objects on every request is a pretty braindead way of doing OO. If you want your application to be brain-live, then you should use Catalyst::Component::InstancePerContext.

    (appears in POD for Catalyst::Component::ACCEPT_CONTEXT - which I was reviewing because of your email... apparently I must have read this once and told my self "Never do this")


    Ben
    --
    Ben Hitz
    Senior Scientific Programmer ** Saccharomyces Genome Database ** GO Consortium
    Stanford University ** hitz@genome.stanford.edu
  • Alejandro Imass at May 20, 2011 at 6:22 pm
    On Thu, May 19, 2011 at 7:06 PM, Benjamin Hitz wrote:

    [...]
    Would like to see that. ?Some of us don't follow all this abstract computer science jargon that well.
    Granted, after re-reading my posts _I_ don't even understand them
    Also - can you comment on the following:

    WARNING WARNING WARNING

    Using this module is somewhat of a hack. Changing the state of your objects on every request is a pretty braindead way of doing OO. If you want your application to be brain-live, then you should use Catalyst::Component::InstancePerContext.

    (appears in POD for Catalyst::Component::ACCEPT_CONTEXT - which I was reviewing because of your email... apparently I must have read this once and told my self "Never do this")
    Ok. Why don't we start with a simple and plain definition of what is
    meant by Class "Type" in Catalyst jargon:

    - class
    - instance


    --
    Alex
  • Alejandro Imass at Jul 20, 2011 at 6:25 am

    On Thu, May 19, 2011 at 7:06 PM, Benjamin Hitz wrote:

    Maybe I should craft up some sample code of the three patterns identified:

    1) Catalyst Models Classes: that completely instantiate per request.
    2) Catalyst Model Instances: with wrapper methods
    3) Catalyst Model Instances: with wrapper attributes
    Would like to see that. ?Some of us don't follow all this abstract computer science jargon that well.
    I tried to make it as practical as possible:

    http://wiki.catalystframework.org/wiki/best_practices/models_definitive_guide

    Maybe others can complement with more "M Patterns"

    Best,

    Alejandro Imass
    Also - can you comment on the following:

    WARNING WARNING WARNING

    Using this module is somewhat of a hack. Changing the state of your objects on every request is a pretty braindead way of doing OO. If you want your application to be brain-live, then you should use Catalyst::Component::InstancePerContext.

    (appears in POD for Catalyst::Component::ACCEPT_CONTEXT - which I was reviewing because of your email... apparently I must have read this once and told my self "Never do this")


    Ben
    --
    Ben Hitz
    Senior Scientific Programmer ** Saccharomyces Genome Database ** GO Consortium
    Stanford University ** hitz@genome.stanford.edu




    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • Alejandro Imass at Jul 20, 2011 at 2:00 pm

    On Wed, Jul 20, 2011 at 2:25 AM, Alejandro Imass wrote:
    On Thu, May 19, 2011 at 7:06 PM, Benjamin Hitz wrote:
    [...]
    I tried to make it as practical as possible:

    http://wiki.catalystframework.org/wiki/best_practices/models_definitive_guide

    Maybe others can complement with more "M Patterns"
    The Catalyst Wiki seems to be having some problems so i posted it on PM as well:

    http://www.perlmonks.org/?node_id�5657


    Best,

    Alejandro Imass
    [...]
  • Ashley Pond V at Jul 20, 2011 at 2:07 pm

    On Wed, Jul 20, 2011 at 7:00 AM, Alejandro Imass wrote:
    On Wed, Jul 20, 2011 at 2:25 AM, Alejandro Imass
    wrote:
    On Thu, May 19, 2011 at 7:06 PM, Benjamin Hitz wrote: [...]
    I tried to make it as practical as possible:

    http://wiki.catalystframework.org/wiki/best_practices/models_definitive_guide

    Maybe others can complement with more "M Patterns"
    The Catalyst Wiki seems to be having some problems so i posted it on PM as well:

    http://www.perlmonks.org/?node_id�5657
    You probably never saw it but I did a bunch of this a couple years
    ago. It's a bit old but contains a lot of good stuff anyway:
    http://sedition.com/a/2733

    And the code with a couple other pieces I didn't really cover in the
    articles is here: https://github.com/pangyre/p5-myapp-10in10
  • Alejandro Imass at Jul 20, 2011 at 2:14 pm

    On Wed, Jul 20, 2011 at 10:07 AM, Ashley Pond V wrote:
    On Wed, Jul 20, 2011 at 7:00 AM, Alejandro Imass
    wrote:
    On Wed, Jul 20, 2011 at 2:25 AM, Alejandro Imass
    [...]
    You probably never saw it but I did a bunch of this a couple years
    ago. It's a bit old but contains a lot of good stuff anyway:
    http://sedition.com/a/2733

    And the code with a couple other pieces I didn't really cover in the
    articles is here: https://github.com/pangyre/p5-myapp-10in10
    Great! Let me go through it and combine all this info into a single
    place. For now I will update the PM node until the Cat Wiki revives.
  • Octavian Rasnita at Jul 24, 2011 at 12:41 pm
    From: "Ashley Pond V" <apv@sedition.com>
    On Wed, Jul 20, 2011 at 7:00 AM, Alejandro Imass
    wrote:
    On Wed, Jul 20, 2011 at 2:25 AM, Alejandro Imass
    wrote:
    On Thu, May 19, 2011 at 7:06 PM, Benjamin Hitz wrote: [...]
    I tried to make it as practical as possible:

    http://wiki.catalystframework.org/wiki/best_practices/models_definitive_guide

    Maybe others can complement with more "M Patterns"
    The Catalyst Wiki seems to be having some problems so i posted it on PM as well:

    http://www.perlmonks.org/?node_id�5657
    You probably never saw it but I did a bunch of this a couple years
    ago. It's a bit old but contains a lot of good stuff anyway:
    http://sedition.com/a/2733
    This address cannot be found.


    Octavian
  • Darius Jokilehto at Aug 2, 2011 at 10:45 am

    On 20/07/11 15:00, Alejandro Imass wrote:
    The Catalyst Wiki seems to be having some problems so i posted it on PM as well:

    http://www.perlmonks.org/?node_id�5657
    In your first example,

    $c->model('Models::People')->all()

    and

    $c->model('Models')->schema->resultset('People');


    are not (necessarily) equivalent. The former always returns an array,
    the latter only in array context.
    Best,

    Alejandro Imass

    NET-A-PORTER.COM
    Irresistible fashion at your fingertips

    ______________________________________________________________________

    CONFIDENTIALITY NOTICE
    The information in this email is confidential and is intended solely for the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, you must not read, use or disseminate the information. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Net a Porter Ltd.

    Net A Porter Ltd is a company registered in England & Wales Number: 3820604 Registered Office: 1 The Village Offices, Westfield, Ariel Way, London, W12 7GF
    _____________________________________________________________________
  • Darius Jokilehto at Aug 2, 2011 at 10:48 am

    On 02/08/11 11:45, Darius Jokilehto wrote:
    are not (necessarily) equivalent. The former always returns an array,
    the latter only in array context.
    Oops, *list* context


    NET-A-PORTER.COM
    Irresistible fashion at your fingertips

    ______________________________________________________________________

    CONFIDENTIALITY NOTICE
    The information in this email is confidential and is intended solely for the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, you must not read, use or disseminate the information. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Net a Porter Ltd.

    Net A Porter Ltd is a company registered in England & Wales Number: 3820604 Registered Office: 1 The Village Offices, Westfield, Ariel Way, London, W12 7GF
    _____________________________________________________________________
  • Alejandro Imass at Aug 2, 2011 at 11:16 am

    On Tue, Aug 2, 2011 at 6:45 AM, Darius Jokilehto wrote:
    On 20/07/11 15:00, Alejandro Imass wrote:

    The Catalyst Wiki seems to be having some problems so i posted it on PM as
    well:

    http://www.perlmonks.org/?node_id�5657
    In your first example,

    ?$c->model('Models::People')->all()

    and

    ?$c->model('Models')->schema->resultset('People');


    are not (necessarily) equivalent. The former always returns an array, the
    latter only in array context.
    Yes, thanks for pointing this out. Assigning to @array saves a lot of
    explaining. My idea is to focus the guide on the design patterns of
    the M layer, not the details of DBIC workings, so I tried to keep the
    examples "equivalent" to make the point.

    Thanks,

    --
    Alejandro Imass
  • Peter Flanigan at Jul 20, 2011 at 4:50 pm

    In this example

    package Models::Model::HomeGrownModel;

    use base 'Catalyst::Model';

    use HomeGrown;

    sub COMPONENT {
    my ( $self, $app ) = @_;
    my $dbic_schema = $app->model('ModelsDB')->schema;
    return HomeGrown->new( schema => $dbic_schema );
    }

    how are you ensuring 'ModelsDB' has been instantiated before
    'HomeGrownModel'?

    --

    Regards
  • Tomas Doran at Jul 20, 2011 at 5:15 pm

    On 20 Jul 2011, at 17:50, Peter Flanigan wrote:
    how are you ensuring 'ModelsDB' has been instantiated before
    'HomeGrownModel'?
    Random chance? :)

    Cheers
    t0m
  • Alejandro Imass at Jul 28, 2011 at 7:22 pm

    On Wed, Jul 20, 2011 at 12:50 PM, Peter Flanigan wrote:
    In this example

    ? ?package Models::Model::HomeGrownModel;

    ? ?use base 'Catalyst::Model';

    ? ?use HomeGrown;

    ? ?sub COMPONENT {
    ? ? ?my ( $self, $app ) = @_;
    ? ? ?my $dbic_schema = $app->model('ModelsDB')->schema;
    ? ? ?return HomeGrown->new( schema => $dbic_schema );
    ? ?}

    how are you ensuring 'ModelsDB' has been instantiated before
    'HomeGrownModel'?
    I updated the Perlmonks article and the code in SVN to reflect this fix.

    http://www.perlmonks.org/?node_id�5657

    Thanks for pointing this out.
    I will proceed to update the Catalyst Wiki as well....

    --
    Alejandro
    --

    Regards

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • Alejandro Imass at Aug 2, 2011 at 10:23 am

    On Thu, Jul 28, 2011 at 3:22 PM, Alejandro Imass wrote:
    On Wed, Jul 20, 2011 at 12:50 PM, Peter Flanigan wrote:
    On 20/07/11 07:25, Alejandro Imass wrote:
    [...]
    I updated the Perlmonks article and the code in SVN to reflect this fix.

    http://www.perlmonks.org/?node_id�5657

    Thanks for pointing this out.
    I will proceed to update the Catalyst Wiki as well....
    FYI there was still another bug in the initialization code for
    modelthree, so I re-wrote it to make it clearer and more elegant.

    Best,

    --
    Alejandro Imass

    --
    Alejandro
    --

    Regards

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • Benjamin Hitz at Jul 22, 2011 at 3:46 pm
    Alejandro -
    thanks for this, it's quite clear.... I had forgotten that I asked for it even.

    Ben
    On Jul 19, 2011, at 11:25 PM, Alejandro Imass wrote:
    On Thu, May 19, 2011 at 7:06 PM, Benjamin Hitz wrote:

    Maybe I should craft up some sample code of the three patterns identified:

    1) Catalyst Models Classes: that completely instantiate per request.
    2) Catalyst Model Instances: with wrapper methods
    3) Catalyst Model Instances: with wrapper attributes
    Would like to see that. Some of us don't follow all this abstract computer science jargon that well.
    I tried to make it as practical as possible:

    http://wiki.catalystframework.org/wiki/best_practices/models_definitive_guide

    Maybe others can complement with more "M Patterns"

    Best,

    Alejandro Imass
    Also - can you comment on the following:

    WARNING WARNING WARNING

    Using this module is somewhat of a hack. Changing the state of your objects on every request is a pretty braindead way of doing OO. If you want your application to be brain-live, then you should use Catalyst::Component::InstancePerContext.

    (appears in POD for Catalyst::Component::ACCEPT_CONTEXT - which I was reviewing because of your email... apparently I must have read this once and told my self "Never do this")


    Ben
    --
    Ben Hitz
    Senior Scientific Programmer ** Saccharomyces Genome Database ** GO Consortium
    Stanford University ** hitz@genome.stanford.edu




    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    --
    Ben Hitz
    Senior Scientific Programmer ** Saccharomyces Genome Database ** GO Consortium
    Stanford University ** hitz@stanford.edu
  • Alejandro Imass at Jul 28, 2011 at 3:11 pm

    On Fri, Jul 22, 2011 at 11:46 AM, Benjamin Hitz wrote:
    Alejandro -
    thanks for this, it's quite clear.... I had forgotten that I asked for it even.

    Ben

    Yeah I had this pending because I think it's very frustrating for many
    people that, even by buying commercial Catalyst books, they tell them
    __what__ to do with models but now exactly __how__.

    There is a potential bug in the example code as Peter Flanigan pointed
    out, but it works every sigle time I've tested it. It seems to
    coincide with this thread from jerome.eteve at gmail May 29, 2010,
    5:08 AM, that nobody answered. I am getting the same "Surprisingly,
    this works...." result as he explained:

    http://www.gossamer-threads.com/lists/catalyst/users/26974?search_string=order;#26974

    In this other thread:

    http://www.gossamer-threads.com/lists/catalyst/users/27169?search_string=order;#27169

    There is a recomendation by Thomas Doran to delay the instantiation of
    the model using Moose after with something like this:

    after setup_components => sub {
    my $app = shift;
    for (keys %{ $app->components }) {
    $app->components->{$_}->initialize_after_setup($app) if $app-
    components->{$_}->can('initialize_after_setup');
    }
    };

    I am still trying to understand the different instatiation-order
    options and to modify my sample code accordingly. In any case, the
    point of these examples are to give some guide on the different
    options that people have when designing and constructing their M layer
    for catalyst applications. I will post the revised article and update
    the sample code when I get a chance....

    --
    Alejandro
  • Eden Cardim at May 18, 2011 at 4:48 pm
    "Octavian" == Octavian Rasnita writes:
    Octavian> If you pass the context $c to the business model, and the business model
    Octavian> would need to access the attributes and methods offered by $c, then you
    Octavian> won't be able to use that business model outside of Catalyst because you
    Octavian> won't have the context variable available.

    Technically, that isn't true. Given this is perl, we don't have implicit
    type-checking, so you can always use duck typing, ie, build a class that
    mimics all the methods available to $c and sons. The real issue is that
    your API will be laden with web-based semantics, not business
    semantics. The focal point of me bringing this up is that the
    implementation is barely what matter in a discussion like this, it's
    always about the API semantics.

    --
    Eden Cardim Need help with your Catalyst or DBIx::Class project?
    Code Monkey http://www.shadowcat.co.uk/catalyst/
    Shadowcat Systems Ltd. Want a managed development or deployment platform?
    http://blog.edencardim.com/ http://www.shadowcat.co.uk/servers/
  • Alejandro Imass at May 19, 2011 at 8:04 am

    On Wed, May 18, 2011 at 12:48 PM, Eden Cardim wrote:
    "Octavian" == Octavian Rasnita <octavian.rasnita@ssifbroker.ro> writes:
    ? ?Octavian> If you pass the context $c to the business model, and the business model
    ? ?Octavian> would need to access the attributes and methods offered by $c, then you
    ? ?Octavian> won't be able to use that business model outside of Catalyst because you
    ? ?Octavian> won't have the context variable available.

    Technically, that isn't true. Given this is perl, we don't have implicit
    type-checking, so you can always use duck typing, ie, build a class that
    mimics all the methods available to $c and sons. The real issue is that
    your API will be laden with web-based semantics, not business
    semantics. The focal point of me bringing this up is that the
    implementation is barely what matter in a discussion like this, it's
    always about the API semantics.
    Yes. In fact there is a lot of stuff I forgot to mention in the
    postulated patterns. What I have been doing is standardizing an
    'entity' data structure that _is the api_ between the cat/web-based
    semantics and the business logic. The concept of 'state' goes well
    with business class and with Web/REST

    The 'entity' is instantiated by the per-request object and accumulates
    transactions and data during the execution of the request. It's a
    pure-perl/Moose object that is passed back and forth and in the end is
    returned to the controller for rendering. It has methods to return
    itself ->as_hash for example so it can be digested by a TT view or
    methods as_json if you are not using something like CC::REST.

    Usually most business logic revolves around some sort of state
    machine, workflow so it's basically tracking entering state,
    intermediate states and transactions and a resulting state. As stated
    This abstraction also pairs well with both EPC (Event Driven Process
    Chains) and with REST ;-) (i.e. the entity is a whole and represents
    it's state, the entity can be a data object or a business process
    object).

    What I'm not exactly sure is about the way we are using Catalyst Model
    Instances. For us all this trouble of instances is mainly to load as
    much business logic code as possible when starting the app and
    minimizing the per-request loading and unloading of heavy-duty code.
    The questions mainly revolve around this (see my OP).

    --
    Alejandro Imass

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedMay 18, '11 at 2:58a
activeAug 2, '11 at 11:16a
posts21
users9
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase