On Wed, May 18, 2011 at 1:42 AM, Octavian Rasnita <octavian.rasn...@ssifbroker.ro> wrote: > From: "Alejandro Imass" <alejandro.im...@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 _______________________________________________ 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/