Sorry, wrong subject...reposting...
On Jun 7, 2007, at 3:53 AM, Jonathan Swartz wrote:
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 than
>>>>> 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
aren't.
>>> 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.
Jon
_______________________________________________
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/