Hi Gerald,
On Sun, Jul 08, 2001 at 03:06:37PM +0200, Gerald Richter wrote:
> That's the intented behaviour, because the Embperl Request object is
> the way how different pages can communicate (pass data back and
> forth). That's the same for %fdat, %udat etc. (and the %ENV is always
> a Perl global)
Yes, they're globals, but aren't they re-initialised at the beginning
of each request? So that the Request object is used to pass data around
between objects in a single page, rather than between pages? Likewise
%fdat and %ENV. %udat and %mdat are probably different because their
whole purpose is to provide persistence between pages ...
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.
> > I've worked around this by just saving and restoring what I'm interested
> > in, but I'm wondering whether it's feasible for EmbperlObject to handle
> > this more gracefully?
>
> If you have any ideas how to improve this, I would be very happy to hear
> about them
Can you have an embedded call to EmbperlObject::Execute take a copy of
$req, %fdat, and %ENV, for example, and then reset $req and %fdat to
empty hashes before you begin the Execute, so they look just like I'd
see if I called the embedded page directly? After the Execute you'd
restore all three with your copies, effectively discarding whatever
changes have happened with the embedded page. (This could be a flag to
Execute in case people also want the current behaviour.)
I'm not familiar enough with Apache/Embperl internals to know if this
makes sense or if I'm missing something obvious ...
Cheers,
Gavin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
