On Sun, Jul 18, 2010 at 6:47 PM, Tomas Doran wrote:
>
> On 18 Jul 2010, at 21:42, Alejandro Imass wrote:
>>
[..,]
>
> No, Catalyst::Model::Factory does _exactly_ and _only_ this for you, so you
> probably/possibly want to use that rather than writing it yourself :)
>
Yeah, I saw the POD on CPAN a
On 18 Jul 2010, at 21:42, Alejandro Imass wrote:
Ok. already! ;-) I have a big bump in my forehead from all this
headbanging. With the headache and all I think I finally
understand...I hope... In my case I need a model that creates an
object to handle every request individually so:
Yep, you g
On Sun, Jul 18, 2010 at 3:36 PM, Tomas Doran wrote:
>
> On 18 Jul 2010, at 19:58, Alejandro Imass wrote:
>
>> So in conclusion, it seems reasonable to say that I should not worry
>> about the global vars (the Moose object attributes) in my Model
>> Instance to get overridden by the ACCEPT_CONTEXT
On 18 Jul 2010, at 19:58, Alejandro Imass wrote:
So in conclusion, it seems reasonable to say that I should not worry
about the global vars (the Moose object attributes) in my Model
Instance to get overridden by the ACCEPT_CONTEXT call, as this call
will only be called once in sequence with a s
On Sun, Jul 18, 2010 at 2:23 PM, Alejandro Imass
wrote:
> On Sun, Jul 18, 2010 at 12:29 PM, Tomas Doran wrote:
>>
>> On 17 Jul 2010, at 18:58, Alejandro Imass wrote:
>>>
[..]
>> Perl code isn't in the 'code segment' of your process.
>>
>> As it's compiled and run dynamically, after all. :)
>>
>>
On Sun, Jul 18, 2010 at 12:29 PM, Tomas Doran wrote:
>
> On 17 Jul 2010, at 18:58, Alejandro Imass wrote:
>>
>> I am confused now. mod_worker will share the same code segment for
>> sure, and if you said earlier that in some scenarios where the code
>> segment is shared (i.e. two _threads_ using t
On 17 Jul 2010, at 18:58, Alejandro Imass wrote:
I am confused now. mod_worker will share the same code segment for
sure, and if you said earlier that in some scenarios where the code
segment is shared (i.e. two _threads_ using the same model instance)
the ACCEPT_CONTEXT call will override any g
On Fri, Jul 16, 2010 at 3:32 AM, Tomas Doran wrote:
>
> On 15 Jul 2010, at 21:37, Alejandro Imass wrote:
>
>> On Mon, Jul 12, 2010 at 3:08 PM, Tomas Doran
>> wrote:
>>>
>>> Each process is in a separate memory space if you're using FCGI or
>>> mod_perl
>>> or something, but it's not entirely cert
On 15 Jul 2010, at 21:37, Alejandro Imass wrote:
On Mon, Jul 12, 2010 at 3:08 PM, Tomas Doran
wrote:
Each process is in a separate memory space if you're using FCGI or
mod_perl
or something, but it's not entirely certain (if you use
Catalyst::Engine::PSGI and Corona (for example) then mult
On Mon, Jul 12, 2010 at 3:08 PM, Tomas Doran wrote:
>
[...]
> Each process is in a separate memory space if you're using FCGI or mod_perl
> or something, but it's not entirely certain (if you use
> Catalyst::Engine::PSGI and Corona (for example) then multiple requests can
> be in-flight and shari
On 12 Jul 2010, at 15:34, Derek Wueppelmann wrote:
On Sat, 2010-07-10 at 13:37 -0400, Alejandro Imass wrote:
If in a Catalyst::Component, say an extension of Catalyst::Model, the
attributes of my instance are also per-request. In other words if I
do
$self->yuca($c->stash->{yuca}) in ACCEPT_
On Sat, 2010-07-10 at 13:37 -0400, Alejandro Imass wrote:
> If in a Catalyst::Component, say an extension of Catalyst::Model, the
> attributes of my instance are also per-request. In other words if I do
> $self->yuca($c->stash->{yuca}) in ACCEPT_CONTEXT and return $self,
> will $self->yuca in the M
Hi,
If in a Catalyst::Component, say an extension of Catalyst::Model, the
attributes of my instance are also per-request. In other words if I do
$self->yuca($c->stash->{yuca}) in ACCEPT_CONTEXT and return $self,
will $self->yuca in the Model _instance_ in a separate memory space
for this request?
13 matches
Mail list logo
