[Catalyst] DNS as a Catalyst Model

Jonathan Swartz swartz at pobox.com
Thu Jun 7 11:53:35 GMT 2007

mia wrote:
 >Matt S Trout wrote:
 >> On Wed, Jun 06, 2007 at 02:18:33PM -0700, mla wrote:
 >>> Matt S Trout wrote:
 >>>> On Wed, Jun 06, 2007 at 12:29:12PM -0700, mla wrote:
 >>>>> Is it not possible to offer the current Catalyst instance through
 >>>>> a class method? Something analogous to Apache->request, rather  
 >>>>> having to do the whole ACCEPT_CONTEXT prototype object thing?
 >>>> Not without limiting ourselves in terms of planned future  
features. Jifty
 >>>> does this because they're explicitly one app per process. We  
 >>> When you say "per process," you mean operating system process?
 >>> You're talking about threading issues?
 >> Threading, forking, and OS-level COW.
 >Forking and COW would apply just as much to instances though.
 >Assuming I'm not using threads, how would I hurt myself by
 >subclassing Catalyst and supplying a MyApp->context that returns
 >the current catalyst context?

Yes, I'd like to know more about this too please. Mason has a similar  
construct - HTML::Mason::Request->instance() - and it works fine with  
Mason subrequests or recursive calls to an entirely different Mason  
interpreter. It just returns the value of a dynamically scoped  
variable that is set at the beginning of a Mason request.

I dislike the fact that anything that needs to access the current  
context object has to be written as a component, and thus have a  
completely different calling signature than just a plain extension.


More information about the Catalyst mailing list