Neil,
the main problem with your idea, that I currently have, is in which files
these globals should be accessable. As I understand you right, you would
make it accessable from all files which are used in one request, while this
makes sense, it is not very efficient. Normaly I try to setup all those
things only once, so any further request doesn't have to do it again. If I
would resetup those globals (which would be actualy aliases to one global),
for every request I can simply do this with all files which are handled in
this request, but if I don't want to resetup it every time, there must be
some way to tell Embperl, which pages belong together and should share the
same globals.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
----- Original Message -----
From: "Neil Gunton" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 09, 2001 6:37 PM
Subject: Re: (possibly stupid) idea for EmbperlObject variables
> Gerald Richter wrote:
> >
> > Neil,
> >
> > first of all it would be possible. Because more people already run
across
> > this problem (even without EmbperlObject), I have somewhere in my mind
the
> > idea of an export or share parameter for Execute, something like
> >
> > Execute ({inputfile => '*', export => ['$foo', '@bar']}) ;
> >
> > then $foo and @bar will be exported in the called package. So you can
access
> > them from both packages like a normal global variable.
> >
> > Would this solve your problem, or do you think adding this parameter to
> > every Execute would mean to much overhead for you ?
>
> This is an interesting idea, and it would definitely be useful in some
> circumstances (e.g. where you want to keep strict control over what is
> passed around). But in my case I have a whole set of files which have
> been split up for the purposes of modularity, but they are all
> conceptually part of the same web page; so it is quite possible that one
> page might want to set a variable that is then used by another page. The
> thing is, the first file is not Executing the second file directly -
> they are both included from base.html. So, it would be non-intuitive to
> require base.html to be aware of all variables which need to be shared
> between files.
>
> I think it would be useful to at least have the option of this global
> hash, the contents of which are set as real variables in each page in
> the request. Sure, it's open to abuse and bad programming, but so is a
> lot of stuff in Perl. I am still not too sure if the global hash is the
> best way to go. In a nutshell, what I want to end up with is the ability
> to do something like the following:
>
> /base.html
>
> [- $req = shift; $global = shift; -]
> [- $global->{foo} = "hello" -]
> [- Execute ('one.html') -]
> [- Execute ('two.html')
>
> /one.html
>
> [- $req = shift; $global = shift; -]
> [+ $foo +]
> [- $foo = "goodbye" -]
> [- $global->{bar} = "whatever" -]
>
> /two.html
>
> [+ $foo +]
> [+ $bar +]
>
> Then, the output from this might be something like
>
> hello goodbye whatever
>
> Does this make sense? The main point is that we reference these
> variables just like any other variables. You say this is possible, which
> sounds great. It does give control over what is made global, because
> only variables which are set in %global are passed into subsequent
> files.
>
> On the downside, it is not immediately apparent that these variables are
> global, so again it opens up the potential for obscure bugs. But the
> power and relative elegance of the feature could outweigh this.
>
> I am not really pushing for this, because I am quite happy right now
> with the way I have Embperl set up. But it just occurred to me as a
> potential way to get around the annoying problem of variables which are
> logically global to any given request...
>
> How hard would this be to implement? Any idea?
>
> Comments, flames etc welcomed...
>
> -Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
