On Mon, Jul 09, 2001 at 12:22:10PM +0200, Gerald Richter wrote:
> > If that's correct, then I was thinking of my embedded
> > EmbperlObject::Execute as a (logical) new request, and expecting that
> > $req would be empty like it is if I access that page directly.
>
> How should Embperl determinate that this Execute call is a new request,
> while when you simply include another file e.g. a header, it isn't a new
> request ?
Oh, I'd been assuming that the include Execute was a different beast
altogether - probably an Embperl::Execute in the context of your
EmbperlObject stuff rather than an EmbperlObject::Execute - that's
obviously not the case.
I'm using these quite differently though - my include Executes are
typically simple and never use the EMBPERL_OBJECT* parameters - they
feel like Embperl::Executes within an EmbperlObject search path context.
My 'new' request, on the other hand, is setting all the EMBPERL_OBJECT
parameters, creating a whole new EmbperlObject context.
How are other people using these? My guess would be most people never
mess with the EMBPERL_OBJECT* parameters from their Executes at all.
> I guess a flag would be neccessary to tell Embperl that this should be s
> separate request and not an include of another page.
Or you could split Execute into a simpler
Execute-In-Current-EmbperlObject-Context and a more complex
Create-New-EmbperlObject-Context if there was any simplicity or
performance benefit that way.
Cheers,
Gavin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
