You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by Neil Gunton <ne...@nilspace.com> on 2000/12/12 19:36:07 UTC
Possible bug with EmbperlObject and [$ sub $]
Gerald, I am having a problem with [$ sub $] and EmbperlObject. Let me
say first that this minimal case does in fact work as it should. There
is something inexplicable going on however in my (much larger) project.
If you look at this minimal case though I think you will see why I don't
think this is a problem with my code.
Let's say I am using EmbperlObject, and EMBPERL_OBJECT_BASE is set to
base.html, and all base.html does is to Execute('*'). Then have a
subroutine under one subdirectory (relative to the website root), say
/foo/index.html, which contains:
[$ sub xxxx $]
foo
[$ endsub $]
[- xxxx -]
And if I use the same name for another subroutine under a completely
different subtree, say /bar/index.html:
[$ sub xxxx $]
bar
[$ endsub $]
[- xxxx -]
These two subroutines should be completely independent, right? But they
don't seem to be. Like I said, in the minimal case example it does seem
to work as normal. But the same situation in my larger project seems to
use the /foo/ version of the subroutine when I am executing
/bar/index.html. This only seems to happen if I have just visited
/foo/index.html, and then go over to /bar/index.html. So it looks like
some kind of caching issue. In fact, I can hit "reload" on the browser
at some later date, and it will reload with the right subroutine being
called. And if I change the name of the subroutines so that they are
different, then all works as it should, every time. But I don't see why
they should clash at all, given that they are on completely different
subtrees.
Any clues much appreciated!
TIA
-Neil
p.s. I just upgraded to 1.3.0.
Re: Possible bug with EmbperlObject and [$ sub $]
Posted by Neil Gunton <ne...@nilspace.com>.
Gerald Richter wrote:
>
> > Gerald, I am having a problem with [$ sub $] and EmbperlObject. Let me
> > say first that this minimal case does in fact work as it should. There
> > is something inexplicable going on however in my (much larger) project.
> > If you look at this minimal case though I think you will see why I don't
> > think this is a problem with my code.
> >
>
> Neil, I didn't had the time to look thru that in detail, but I do it as soon
> as possible and let you know
Gerald, I have been playing around with this thing and I have discovered
something that may be of some use in finding the bug. When I call the [$
sub foo $] subroutines via the simple [- foo -] form, the problem
occurs. However when I call the subroutine using the form [- Execute
('#foo') -] the bug does not manifest. I believe the two forms should be
equivalent in behavior (for simple cases, not involving state or
recursion). The calling mechanisms are obviously very different, it's
just interesting to note that the simple Perl method of calling the [$
sub $] seems to get confused with another subroutine of the same name,
in a completely different directory subtree.
Also, I have noticed that even calling a non-existent subroutine name
does not appear to generate an error, when using the [- xxxx -] form.
There is simply no output. However the [- Execute('#xxxx') -] form does
generate an error.
I hope this is of some help...
-Neil
Re: calling methods within EmbperlObject
Posted by Neil Gunton <ne...@nilspace.com>.
> the other solution would be to change it to
>
> [- Execute ('subs.html#NEW', \$object) -]
Gerald, I should have spotted that myself - this small example works
now. I will play with it for a bit and see how it looks in my (somewhat
larger) projects... I'll let you know if any more problems/ideas hit me
regarding this issue.
I take it this is a more memory-efficient solution than the one I was
using (i.e. importing every file using the same __PACKAGE__). If so then
I can live with the small extra bit of coding required in order to call
methods across the package bounderies.
Thanks again! It's great to get this working.
/Neil
Re: calling methods within EmbperlObject
Posted by Gerald Richter <ri...@ecos.de>.
> [- Execute ({inputfile => 'subs.html#NEW', param => \@p}) -]
Oops, sorry my fault, must be:
[- Execute ({inputfile => 'subs.html', sub => 'NEW', param => \@p}) -]
the 'subs.html#NEW' works only in the short syntax, i.e.
[- Execute ('subs.html#NEW') -]
the other solution would be to change it to
[- Execute ('subs.html#NEW', \$object) -]
this passes in a reference ro $object and then
[$ sub NEW $]
[-
my $object = {};
bless $object, __PACKAGE__;
${$param[0]} = $object;
-]
[$ endsub $]
[! sub xxx { print OUT "xxx"; } !]
This is a little shorter and saves the extra @p array
Gerald
Re: calling methods within EmbperlObject
Posted by Neil Gunton <ne...@nilspace.com>.
Gerald, you hit the nail on the head this time. This is exactly what I
was talking about. I apologise if I sounded a bit frustrated last email
- I've really been thrown by this thing over the last few days. It's
make me question everything I was doing, and after 8 months that's quite
a lot of code ...
Anyhow, I want to thank you again for taking the time to address these
things. I tried your proposal, which I think should work, but doesn't
seem to for me. Here's what I have:
base.html:
<HTML>
[- Execute ({inputfile => 'subs.html', import => 0}) -]
[- Execute ({inputfile => 'subs.html#NEW', param => \@p}) -]
[-
$object = $p[0];
$object->xxx;
-]
</HTML>
subs.html:
[$ sub NEW $]
[-
my $object = {};
bless $object, __PACKAGE__;
$param[0] = $object;
-]
[$ endsub $]
[! sub xxx { print OUT "xxx"; } !]
When I try this, I get an error in base.html, as follows:
[494]ERR: 30: Line 3: Not found subs.html#NEW
[494]ERR: 24: Line 4: Error in Perl code: Can't call method "xxx" on an
undefined value
at /www/nilspace/com/test/base.html line 6.
Apache/1.3.12 Ben-SSL/1.41 (Unix) mod_perl/1.24 AuthMySQL/2.20
HTML::Embperl 1.3.0
Oh boy. Am I doing something stupid here? It looks ok to me...
This method looks at first sight to offer the functionality needed to
make my multi-package scenario workable. I am not sufficiently
experienced in Perl wizardry to be able to offer much more in the way of
elegant ideas at this point... I guess with real use the best way to do
this will become apparent.
Anyway, thanks again Gerald! I feel like we are making progress now...
-Neil
Re: calling methods within EmbperlObject
Posted by Neil Gunton <ne...@nilspace.com>.
Wow! Thanks, Gerald. I will try this stuff out over this weekend. It
certainly looks good.
I hope you can get away now and do real holiday stuff!
Best wishes
-Neil
Gerald Richter wrote:
>
> Neil,
>
> I have found a small free time slot and instead of doing nice things I have
> sit in front of my computer and hacked a little bit at the things we talk
> about yesterday. I just have commited a change to the CVS that allows you to
> do the following:
>
> [- $subs = Execute ({'object' => 'eposubs.htm'}) -]
>
> txt1: [+ $subs -> txt1 +] <br>
>
> txt2: [+ $subs -> txt2 +] <br>
>
> This call to Execute returns a object reference that is blessed into the
> package of eposubs.htm, just like we did with the NEW sub.
>
> The second thing is
>
> [! Execute ({'isa' => '../eposubs.htm'}) !]
>
> [!
> sub txt1 { "txt1 from same dir" } ;
> !]
>
> This does what Angus suggested with the [$uses foo.epl $], it pushes the
> package of the ../eposubs.htm onto @ISA.
>
> Hope this makes your coding a little bit easier
>
> Gerald
>
> -------------------------------------------------------------
> Gerald Richter ecos electronic communication services gmbh
> Internetconnect * Webserver/-design/-datenbanken * Consulting
>
> Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
> E-Mail: richter@ecos.de Voice: +49 6133 925151
> WWW: http://www.ecos.de Fax: +49 6133 925152
> -------------------------------------------------------------
Re: calling methods within EmbperlObject
Posted by Gerald Richter <ri...@ecos.de>.
Neil,
I have found a small free time slot and instead of doing nice things I have
sit in front of my computer and hacked a little bit at the things we talk
about yesterday. I just have commited a change to the CVS that allows you to
do the following:
[- $subs = Execute ({'object' => 'eposubs.htm'}) -]
txt1: [+ $subs -> txt1 +] <br>
txt2: [+ $subs -> txt2 +] <br>
This call to Execute returns a object reference that is blessed into the
package of eposubs.htm, just like we did with the NEW sub.
The second thing is
[! Execute ({'isa' => '../eposubs.htm'}) !]
[!
sub txt1 { "txt1 from same dir" } ;
!]
This does what Angus suggested with the [$uses foo.epl $], it pushes the
package of the ../eposubs.htm onto @ISA.
Hope this makes your coding a little bit easier
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: calling methods within EmbperlObject (was: Possible bug with EmbperlObject and [$ sub $])
Posted by Gerald Richter <ri...@ecos.de>.
Neil,
>
> Gerald, when I try to move the above Execute statement into a [! !]
> block, before the rest of the action, Embperl gives me an error on the
> line where I call Execute ('subs.html#NEW', \$req->{subs}):
>
without haveing actualy tried it, I would say it should work. I can't see at
the moment why it shouldn't. So maybe it's really a bug in Embperl. I try it
out when I am back and let you know. Until then please use [- -] instead
Gerald
Re: calling methods within EmbperlObject (was: Possible bug with
EmbperlObject and [$ sub $])
Posted by Neil Gunton <ne...@nilspace.com>.
Gerald Richter wrote:
> > base.html
> > [-
> > # Setup other packages
> > $req = shift;
> > Execute ({inputfile => 'subs.html', import => 0});
>
> You could move the import in a [! !] block, so it will only be executed once
> at compile time
>
Gerald, when I try to move the above Execute statement into a [! !]
block, before the rest of the action, Embperl gives me an error on the
line where I call Execute ('subs.html#NEW', \$req->{subs}):
[1203]ERR: 42: Line 1: Call to unknown Embperl macro NEW
This can be made to work again by making the [! !] into [- -]. Is this a
bug then with [! !]? I have also tried with import => 1, same error. I
even tried restarting Apache in case it was caching something.
Actually, the only way I can get this to work with [! !] is as follows:
[! Execute ({inputfile => 'subs.html', package => __PACKAGE__}) !]
So maybe it's not so much a problem with [! !] as with the 'import'
param. I don't know.
If there's something different I should be doing in the call to
Execute() when it is inside [! !], then I apologise, but right now it
looks to me as if there may be a problem. Not a showstopper, for the
time being I'll just use [- -] instead.
/Nil
Re: calling methods within EmbperlObject (was: Possible bug with EmbperlObject and [$ sub $])
Posted by Gerald Richter <ri...@ecos.de>.
>and I will also make a start on some kind of EmbperlObject
> tutorial
Great!
> do you have any
> particular preference that would make it easier for you to integrate?
pod, please write everything in pod. All the Embperl docs are written in pod
and I have a script that generates the whole Embperl website out of this pod
files. Just a few hints:
=head1 starts a new page on the web
=head2 starts a new paragraph which is separated with a line
Just look at Intro.pod and
http://perl.apache.org/embperl/Intro.pod.cont.html for an example.
>
> WHAAAAAT? You're taking Christmas off? Have you no loyalty to the
> Embperl users? :-)
>
Of course I have, otherwise I would turn my computer off after 12 hours of
work, instead of answering questions ;-)
> Have a very good holiday, Gerald!
>
Thanks (don't worry I have understood your above sentence about "loyalty"
right)
>
> p.s. Embperl 2.0 sounds very exciting. I look forward to playing around
> with it.
>
I am looking forward to hear from you :-)
Gerald
Re: calling methods within EmbperlObject (was: Possible bug with
EmbperlObject and [$ sub $])
Posted by Neil Gunton <ne...@nilspace.com>.
Gerald, thanks for the feedback on my EmbperlObject code. I will be
re-working my sites to use the new methodology over Christmas (bah,
humbug), and I will also make a start on some kind of EmbperlObject
tutorial (I will see how it goes, at least it will be a start). I don't
know what format you want the documentation in - do you have any
particular preference that would make it easier for you to integrate? I
assume this will end up on the website, so do you want HTML? Or just
straight text? Or both? If I don't hear from you then I'll just start
off with plain text, it's easy enough to mark up.
> Neil, it isn't so much work to implement this features (some hours, the main
> work on such features is to build the tests) and I would like to implement
> them soon, because I see they are really usefull. Unfortunately we have
> chrismas in front of our door and I will be on holiday until the beginning
> of januray (without any laptop :-) (that's of course only unfortunately for
> you and not for me ;-). I have recently spend much time with Embperl 2.0 and
> of course have to do "some" other work. I try to implement it at the
> beginning of january, but I can't promise you anything.
>
> Sorry, if I can't do it quicker, I also would like to do so
WHAAAAAT? You're taking Christmas off? Have you no loyalty to the
Embperl users? :-)
Have a very good holiday, Gerald!
Thanks again for all your help!
-Neil
p.s. Embperl 2.0 sounds very exciting. I look forward to playing around
with it.
Re: calling methods within EmbperlObject (was: Possible bug with EmbperlObject and [$ sub $])
Posted by Gerald Richter <ri...@ecos.de>.
> It
> seems to me that I will now effectively be referencing all my (formerly
> global) variables through a hash, which seems like it could introduce a
> certain amount of additional overhead (because of the hash lookup every
> time I refer to the variable). Will this appreciably affect performance?
> I suppose it's necessary, so it's a moot point maybe.
>
You are right, it introduces some overhead, but I don't think it's too much.
That's the way class data is handled in OO Perl. It's a general drawback of
OO technologie, that it introduce some overhead, but it gives you other
benefits...
>
> Also, I store the package name in the hash, so that derived classes can
> change their @ISA. I am not aware of how you might get the package name
> of an object otherwise.
ref ($object) returns the package name of an object
>Maybe there's a better way. Any comments
> welcomed. Anyway, here it is:
>
> base.html
> [-
> # Setup other packages
> $req = shift;
> Execute ({inputfile => 'subs.html', import => 0});
You could move the import in a [! !] block, so it will only be executed once
at compile time
> Execute ('subs.html#NEW', \$req->{subs});
>
> # Example call
> $req->{subs}->xxx;
>
If you need this reference often, I would make a copy in a global and use
that for the method call and the $req->{subs} just for passing around to
other modules. So everything that has to be shared lives in $req->{xxx} and
any local data uses normal Perl variables.
> # Do rest of html
> Execute ('*');
> -]
>
> index.html
> [-
> $req = shift;
>
> # Example call
> $req->{subs}->xxx;
> -]
>
> subs.html
> [$ sub NEW $]
> [-
> my $object = {};
> bless $object, __PACKAGE__;
> $object->{__PACKAGE__} = __PACKAGE__;
> ${$param[0]} = $object;
> -]
> [$ endsub $]
>
> [! sub xxx{ print OUT "xxx"; } !]
>
> foo/subs.html
> [$ sub NEW $]
> [-
> Execute ({inputfile => '../subs.html', import => 0});
> Execute ('../subs.html#NEW', \$object);
>
> # Make sure we inherit from parent
> @ISA = ($object->{__PACKAGE__});
>
> # Keep object, but bless it into this package
> bless $object, __PACKAGE__;
> $object->{__PACKAGE__} = __PACKAGE__;
> ${$param[0]} = $object;
> -]
> [$ endsub $]
>
> [!
> sub xxx
> {
> my $self = shift;
> print OUT "foo/xxx ";
>
> # Example call to parent version
> $self->SUPER::xxx (@_);
> }
> !]
>
> This all seems to work just fine so far. It allows me to have real
> inheritance without including everything in the same package (like I was
> doing before). However as you can see it does involve a fair amount of
> boilerplate code which might be better off living in Embperl.
>
Yes, I like to put it into Embperl.
>
> Gerald, I don't know how much extra work this would be for you.
> Obviously I don't want to rework all my websites to use the methods
> which I give above, if you are going to add something like [$ uses $].
> On the other hand, I do need to get on with stuff... what do you think?
> I'm not trying to be pushy here, just wondering about timescale. If you
> think it's really easy and a matter of a week or something like that
> then I would hold off on rework (and the documentation/examples) so that
> I can use the new version. If you think it would take longer or you are
> very busy right now, then I would just go ahead and change over to doing
> things the way I have it above.
>
Neil, it isn't so much work to implement this features (some hours, the main
work on such features is to build the tests) and I would like to implement
them soon, because I see they are really usefull. Unfortunately we have
chrismas in front of our door and I will be on holiday until the beginning
of januray (without any laptop :-) (that's of course only unfortunately for
you and not for me ;-). I have recently spend much time with Embperl 2.0 and
of course have to do "some" other work. I try to implement it at the
beginning of january, but I can't promise you anything.
Sorry, if I can't do it quicker, I also would like to do so
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: calling methods within EmbperlObject (was: Possible bug with
EmbperlObject and [$ sub $])
Posted by Neil Gunton <ne...@nilspace.com>.
> personally, [$ uses $] is quite enough for me.
>
> a few people seem to expect the [$ uses '../*' $] behaviour when they
> hear talk about search paths and selectively overriding things.
>
> but considering the performance impact, i think it would be best to
> document [$ uses '../*' $] and let people do it themselves.
I think I really like your idea. And I agree, [$ uses '../*' $] can be
optional, it's only one line. I have been playing around with the stuff
that Gerald came up with, and so far I have to do the following to get
the kind of inheritance that I'd like. If I'm doing stupid/unnecessary
stuff with Perl then that's because of my relative inexperience :-)
I'd like to confirm that the method I am using here (passing around a
reference to the 'subs' object in the req) is a sensible thing to do,
and that I am not being inefficient with memory or speed in any way. It
seems to me that I will now effectively be referencing all my (formerly
global) variables through a hash, which seems like it could introduce a
certain amount of additional overhead (because of the hash lookup every
time I refer to the variable). Will this appreciably affect performance?
I suppose it's necessary, so it's a moot point maybe.
Also, I store the package name in the hash, so that derived classes can
change their @ISA. I am not aware of how you might get the package name
of an object otherwise. Maybe there's a better way. Any comments
welcomed. Anyway, here it is:
base.html
[-
# Setup other packages
$req = shift;
Execute ({inputfile => 'subs.html', import => 0});
Execute ('subs.html#NEW', \$req->{subs});
# Example call
$req->{subs}->xxx;
# Do rest of html
Execute ('*');
-]
index.html
[-
$req = shift;
# Example call
$req->{subs}->xxx;
-]
subs.html
[$ sub NEW $]
[-
my $object = {};
bless $object, __PACKAGE__;
$object->{__PACKAGE__} = __PACKAGE__;
${$param[0]} = $object;
-]
[$ endsub $]
[! sub xxx{ print OUT "xxx"; } !]
foo/subs.html
[$ sub NEW $]
[-
Execute ({inputfile => '../subs.html', import => 0});
Execute ('../subs.html#NEW', \$object);
# Make sure we inherit from parent
@ISA = ($object->{__PACKAGE__});
# Keep object, but bless it into this package
bless $object, __PACKAGE__;
$object->{__PACKAGE__} = __PACKAGE__;
${$param[0]} = $object;
-]
[$ endsub $]
[!
sub xxx
{
my $self = shift;
print OUT "foo/xxx ";
# Example call to parent version
$self->SUPER::xxx (@_);
}
!]
This all seems to work just fine so far. It allows me to have real
inheritance without including everything in the same package (like I was
doing before). However as you can see it does involve a fair amount of
boilerplate code which might be better off living in Embperl.
Gus, I think that what I am doing here is pretty much functionally
equivalent to what you are suggesting with [$ uses $]. If I'm wrong then
please tell me how it differs. But your idea is much nicer, IMO.
Gerald, I don't know how much extra work this would be for you.
Obviously I don't want to rework all my websites to use the methods
which I give above, if you are going to add something like [$ uses $].
On the other hand, I do need to get on with stuff... what do you think?
I'm not trying to be pushy here, just wondering about timescale. If you
think it's really easy and a matter of a week or something like that
then I would hold off on rework (and the documentation/examples) so that
I can use the new version. If you think it would take longer or you are
very busy right now, then I would just go ahead and change over to doing
things the way I have it above.
Either way, thanks again, I like the way that EmbperlObject seems to be
headed.
-Neil
Re: calling methods within EmbperlObject (was: Possible bug with EmbperlObject and [$ sub $])
Posted by Angus Lees <gu...@switchonline.com.au>.
On Thu, Dec 21, 2000 at 05:58:46AM +0100, Gerald Richter wrote:
> > another approach, that seems to be what people intuitively want is to
> > have each file inherit from other copies of itself further up the
> > search path. sort of like an implicit [$ uses "../$thisfile" $].
>
> I have considered this when I wrote EmbperlObject, I simply didn't do so for
> performance reasons. If we have the [$ uses ... $] you suggest, anybody can
> simply insert a
>
> [$ uses "../*" $]
>
> at the top of the file that should inherence from it's base. Do you think
> that would be ok, or do you think this should be done automaticly by Embperl
> ?
personally, [$ uses $] is quite enough for me.
a few people seem to expect the [$ uses '../*' $] behaviour when they
hear talk about search paths and selectively overriding things.
but considering the performance impact, i think it would be best to
document [$ uses '../*' $] and let people do it themselves.
--
- Gus
Re: calling methods within EmbperlObject (was: Possible bug with EmbperlObject and [$ sub $])
Posted by Gerald Richter <ri...@ecos.de>.
> an idea i've been considering was to have some sort of:
>
> [$ uses 'subs.epl' $]
>
> command that did:
>
> compile $epl;
> $pkg = package for $epl;
> push @{caller.'::ISA'}, $pkg;
>
Yes, I agree that would be really usefull.
>
> another approach, that seems to be what people intuitively want is to
> have each file inherit from other copies of itself further up the
> search path. sort of like an implicit [$ uses "../$thisfile" $].
>
I have considered this when I wrote EmbperlObject, I simply didn't do so for
performance reasons. If we have the [$ uses ... $] you suggest, anybody can
simply insert a
[$ uses "../*" $]
at the top of the file that should inherence from it's base. Do you think
that would be ok, or do you think this should be done automaticly by Embperl
?
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: calling methods within EmbperlObject (was: Possible bug with EmbperlObject and [$ sub $])
Posted by Angus Lees <gu...@switchonline.com.au>.
an idea i've been considering was to have some sort of:
[$ uses 'subs.epl' $]
command that did:
compile $epl;
$pkg = package for $epl;
push @{caller.'::ISA'}, $pkg;
that way you could selectively insert other embperl files into your
inheritance path, and each individual sub can be overridden as with
normal inheritance rules.
it would have to be done at compile time, so that (eg) subs.epl could
in turn inherit from other files without having to call constructors
everywhere. this means that the "uses" list would have to be kept
somewhere and restored when the file was recompiled (and when packages
are unloaded in embperl2, they need some way of being restored
correctly - simply reference count it and only unload if noone is
using you?).
another approach, that seems to be what people intuitively want is to
have each file inherit from other copies of itself further up the
search path. sort of like an implicit [$ uses "../$thisfile" $].
ie: always search the full path (all the way up to STOPDIR) and for
each file found, add all earlier to @ISA. we have to go all the way to
STOPDIR, so the base itself can use this mechanism too (the base will
probably use this feature most often).
in code:
@search_path = ($STOPDIR .. $actual_epl_filepath);
# walk reversed search path, compile each and add previous to @ISA
foreach (@search_path) {
next unless -r "$_/$epl"
compile "$_/$epl";
$pkg = package for "$_/$epl";
push @{$pkg::ISA}, @pkglist;
push @pkglist, $pkg;
}
(if that makes it any clearer..)
--
- Gus
Re: calling methods within EmbperlObject (was: Possible bug with EmbperlObject and [$ sub $])
Posted by Gerald Richter <ri...@ecos.de>.
>
> Gerald, I hesitate to continue on this because it seems like I keep
> asking the same question. But really, you didn't answer my previous
> query so I have to try again.
Don't hestitate to ask again, if I understand you wrong! Maybe it wasn't
obvious to me what you ment, maybe I simply wasn't able to understand it
after 12 hours of work....
> I understand, I think, the use of Perl
> methods that you refer to above. What this gives you is an inheritance
> hierarchy with the package of the requested page inheriting from the
> base.html. So you can over-ride methods and write global data, which is
> great. What still isn't obvious to me is how you include subroutines (or
> methods!) from *other* files. I don't want to put all my methods in
> base.html or the '*' (i.e. requested) file.
I thought you wanted to call sub's in '*', if they are in other files then
my suggestion doesn't work of course.
> I want to include files like
> 'subs.html' from base.html - and then allow subs.html to be redefined in
> subdirectories. This concept could be widened to include an arbitrary
> number of different packages (classes). I assume that subs.html would in
> turn have its own inheritance hierarchy, but since each document has its
> own package, the methods in subs.html seem to be inaccessible to
> base.html and its children.
Re: calling methods within EmbperlObject (was: Possible bug with
EmbperlObject and [$ sub $])
Posted by Neil Gunton <ne...@nilspace.com>.
Gerald Richter wrote:
>
> Neil,
>
> I think what you need here is to use Perl methods instead of plain
> functions. EmbperlObject bless's the Embperl Request Object into the package
> of the current calling page, so you are able to call the correct subroutine
> by using the method call syntax. (and you don't need to import anything at
> all)
>
> Again look at
>
> http://perl.apache.org/embperl/EmbperlObject.pod.5.html#Example_for_using_me
>
> that should show how it works. If it isn't clear don't hestitate to ask
Gerald, I hesitate to continue on this because it seems like I keep
asking the same question. But really, you didn't answer my previous
query so I have to try again. I understand, I think, the use of Perl
methods that you refer to above. What this gives you is an inheritance
hierarchy with the package of the requested page inheriting from the
base.html. So you can over-ride methods and write global data, which is
great. What still isn't obvious to me is how you include subroutines (or
methods!) from *other* files. I don't want to put all my methods in
base.html or the '*' (i.e. requested) file. I want to include files like
'subs.html' from base.html - and then allow subs.html to be redefined in
subdirectories. This concept could be widened to include an arbitrary
number of different packages (classes). I assume that subs.html would in
turn have its own inheritance hierarchy, but since each document has its
own package, the methods in subs.html seem to be inaccessible to
base.html and its children. I am not an expert Perl programmer, so
perhaps I am missing the simple way of doing this. Is anyone on this
mailing list using EmbperlObject in this way, and if so could you please
provide an example as a design pattern?
This has become a real block for me, and I would like to just get on
with actual implementation rather than batting my head against a brick
wall with basic architecture stuff... I realize that this is a free
email support list, and believe me I am acutely aware of the fact that I
have been asking a lot of questions recently! But I am simply trying to
get the design of my Embperl websites correct, since the way I have been
doing it up to now is obviously incorrect. So I am in the weird position
of having quite a lot of existing code which really does work pretty
well but is (now) obviously wrong. Can anyone enlighten me with a design
pattern for including methods/subroutines from other files while still
using the EmbperlObject framework?
TIA
-Neil
Re: calling methods within EmbperlObject (was: Possible bug with EmbperlObject and [$ sub $])
Posted by Gerald Richter <ri...@ecos.de>.
Neil,
I think what you need here is to use Perl methods instead of plain
functions. EmbperlObject bless's the Embperl Request Object into the package
of the current calling page, so you are able to call the correct subroutine
by using the method call syntax. (and you don't need to import anything at
all)
Again look at
http://perl.apache.org/embperl/EmbperlObject.pod.5.html#Example_for_using_me
that should show how it works. If it isn't clear don't hestitate to ask
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: Possible bug with EmbperlObject and [$ sub $]
Posted by Neil Gunton <ne...@nilspace.com>.
Gerald,
First of all, thanks for taking the time to explain these things. I
understand better now about the problem with using __PACKAGE__ to
include my subroutine files. However I have to admit that I am still
thoroughly confused by the behavior of Execute() with regard to
subdirectories. I just cannot seem to get my subroutines to be visible
unless I use __PACKAGE__. It all works fine in the base directory, but
as soon as I try doing things in subdirectories the subs are invisible -
I get internal server errors whenever I try to call them. I have tried
using every permutation of the 'import' parameter to Execute(), but it
makes no difference. As you say, it will use much more memory if I use
__PACKAGE__, so I do want to get this right.
So, if you have the time, could you please explain for me how I should
implement the following scenario. I have left it as simple as possible,
since I am not sure at this point how to do it. Basically what I want to
here do is include the Perl subroutines from subs.html into base.html,
and then call '*' with those subroutines enabled. So in the '*' file I
should be able to just
call the Perl subs. The thing is, subs.html may be over-ridden in
subdirectories, so we have to make sure that the parent is called.
Here's the general layout:
/base.html
[- Execute ('subs.html') -]
[- Execute ('*') -]
/subs.html
[- sub xxx { print OUT "xxx" } -]
/foo/subs.html
[- Execute ('../subs.html') -]
[- sub foo { print OUT "foo" } -]
/foo/index.html
[- xxx -]
[- foo -]
When I try this exactly as I have it here, the browser just sits and
waits for about 15 seconds, before displaying a message that the
document contained no data. There doesn't seem to be much in the embperl
log either. Should that happen? Should this work as it is?
The key lines here are the Execute() statements. I cannot seem to find a
combination of parameters (e.g. import=>1) which makes /foo/index.html
actually see xxx() and foo(). Here are some specific questions.
1. To enable this scenario, should the calls to Execute() in base.html
use import=>1, or 0, or not at all?
2. Should the call to Execute('../subs.html') in /foo/subs.html be
necessary? I assume it is, if you want to add subroutines to the ones
defined by the parent file.
What form should this call take? Does it need import?
3. Should the call to Execute('*') be as simple as that?
Sorry if this seems like basic stuff, I've actually been using Embperl
for a while now quite happily, but using __PACKAGE__ from base.html to
include subroutines. Since you've pointed out the memory issues with
that (and the problem I just ran into of name conflicts), I really want
to get the architecture right. And I can see how 'import' works in the
simple case, but not when you have subdirectories which over-ride higher
directories.
If you could enlighten me as to what the correct practice is here, I
would be most grateful.
Thanks again,
-Neil
Re: Possible bug with EmbperlObject and [$ sub $]
Posted by Gerald Richter <ri...@ecos.de>.
Neil,
let me start with end of your mail...
> What do you think, Gerald? Does this behavior constitute a bug, or am I
> merely using Embperl incorrectly in this instance?
The second thing is true. Let me explain why it is not a bug:
> I thought that if
> you included a file using
>
> Execute ({inputfile => 'filename.html', package => __PACKAGE__})
>
> then this was _equivalent_ to including that file inline in the current
> file (this was the subject of one of my early questions to the mailing
> list).
No, not fully. You compile the file in the same namespace. From the Perl
point of view it's the same as an inline inlcude, but the Execute ('x#y') is
handled by Embperl itself, and Embperl keeps it's subroutines associated
with filenames and not packagenames. Is this more clear now?
>
> In any case, I believe I have now isolated the minimal case which can
> demonstrate the "error" which I am experiencing. Let's say we are using
> base.html and EmbperlObject as stated previously, and in addition we
> have two files, xxx.html and yyy.html. The files are as follows:
>
> base.html:
> [- Execute ({inputfile => '*', package => __PACKAGE__}) -]
>
> xxx.html:
> [$ sub foo $]
> xxx
> [$ endsub $]
>
> <A HREF="yyy.html">yyy</A>
>
> <H1>xxx: [- foo -]</H1>
>
> yyy.html:
> [$ sub foo $]
> yyy
> [$ endsub $]
>
> <A HREF="xxx.html">xxx</A>
>
> <H1>yyy: [- foo -]</H1>
>
> If you point your browser at xxx.html and then flip between the two
> using the link (making sure you hit "reload" to refresh), you will see
> that the sub foo gets mixed up. So when we are displaying xxx.html,
> sometimes we get the "yyy" string, and vice versa.
>
> Looking at this example, I would have intuitively expected sub foo to be
> independent between xxx.html and yyy.html, because it is locally defined
> in each file. But on the other hand, both xxx.html and yyy.html are
> included from base.html into the same namespace, so I can see why the
> cache might get confused... but still, I feel that the two files should
> be independent. The subs should not be mixed up. Do you agree?
>
No I don't agree. Embperl doesn't mix up the two subroutines, you can call
both with the Execute ('x#y') syntax and it works, but Perl cannot keep them
separate because you compile then in the same namespace. The subrountine
that is compiled as second one, will stay and called for any further
invocation (which sub this is may be different for different Apache childs).
You tell Perl to use the same namespace, you cannot expect that Perl can
define to subroutines with the same name in the same namespace...
>
> I use __PACKAGE__ because I have global variables which are set up in
> various different files (such as init.html and constants.html) which are
> executed before '*', and it is just more convenient to include all these
> in the same namespace. I don't doubt there's some kind of workaround.
>
By includeing them in the same namespace you also need much more memory,
because you have to compile all common files for every file you invoke. To
pass "global" data around, use the Embperl Request Object.
http://perl.apache.org/embperl/EmbperlObject.pod.5.html#Example_for_using_me
thod_calls contains an example (the $self -> {fontsize} )
Hope this helps
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: Possible bug with EmbperlObject and [$ sub $]
Posted by Neil Gunton <ne...@nilspace.com>.
> >but I continue to
> > play with the problem and have come up with more possible behavioral
> > clues. In my previous email, I said that Execute('#foo') worked.
> > However, I now discover that it ONLY works if [$ sub foo $] is in the
> > same file as the call to Execute('#foo'). When I move the [$ sub $]
> > definition out into a subroutines file (which is Executed to import the
> > subs) then I consistently get an error "Call to unknown Embperl macro
> > foo" on Execute('#foo').
>
> This is exactly as it should be. To call an sub in another file via Execute
> you have to provide the filename, e.g.
>
> Execute ('bar.html#foo') ;
Ok - this is different from my previous understanding. I thought that if
you included a file using
Execute ({inputfile => 'filename.html', package => __PACKAGE__})
then this was _equivalent_ to including that file inline in the current
file (this was the subject of one of my early questions to the mailing
list). Hence I thought that
Execute ('#foo')
would work if the file had been included in this way.
In any case, I believe I have now isolated the minimal case which can
demonstrate the "error" which I am experiencing. Let's say we are using
base.html and EmbperlObject as stated previously, and in addition we
have two files, xxx.html and yyy.html. The files are as follows:
base.html:
[- Execute ({inputfile => '*', package => __PACKAGE__}) -]
xxx.html:
[$ sub foo $]
xxx
[$ endsub $]
<A HREF="yyy.html">yyy</A>
<H1>xxx: [- foo -]</H1>
yyy.html:
[$ sub foo $]
yyy
[$ endsub $]
<A HREF="xxx.html">xxx</A>
<H1>yyy: [- foo -]</H1>
If you point your browser at xxx.html and then flip between the two
using the link (making sure you hit "reload" to refresh), you will see
that the sub foo gets mixed up. So when we are displaying xxx.html,
sometimes we get the "yyy" string, and vice versa.
Looking at this example, I would have intuitively expected sub foo to be
independent between xxx.html and yyy.html, because it is locally defined
in each file. But on the other hand, both xxx.html and yyy.html are
included from base.html into the same namespace, so I can see why the
cache might get confused... but still, I feel that the two files should
be independent. The subs should not be mixed up. Do you agree?
I realize now that the crucial thing here is the use of __PACKAGE__ in
the call from base.html. Not having this in my initial minimal case was
why it worked ok, and it is the presence of __PACKAGE__ that causes the
bug (if it is in fact a bug) to manifest.
I use __PACKAGE__ because I have global variables which are set up in
various different files (such as init.html and constants.html) which are
executed before '*', and it is just more convenient to include all these
in the same namespace. I don't doubt there's some kind of workaround.
What do you think, Gerald? Does this behavior constitute a bug, or am I
merely using Embperl incorrectly in this instance?
Anyway, it's a relief to finally pin down exactly what causes this thing
to happen! It was driving me nuts.
Thanks again for your time,
-Neil
Re: Possible bug with EmbperlObject and [$ sub $]
Posted by Gerald Richter <ri...@ecos.de>.
Neil,
>
> Sorry about the repeated emails regarding this issue,
No problem, as more information you can provide for me, as easier it is for
me to find the problem :-)
>but I continue to
> play with the problem and have come up with more possible behavioral
> clues. In my previous email, I said that Execute('#foo') worked.
> However, I now discover that it ONLY works if [$ sub foo $] is in the
> same file as the call to Execute('#foo'). When I move the [$ sub $]
> definition out into a subroutines file (which is Executed to import the
> subs) then I consistently get an error "Call to unknown Embperl macro
> foo" on Execute('#foo').
This is exactly as it should be. To call an sub in another file via Execute
you have to provide the filename, e.g.
Execute ('bar.html#foo') ;
but the file must be already loaded before, to make sure it is, do a
Execute (inputfile => 'bar.html', import => 0) ;
before. (This import => 0 isn't neccessary anymore in Embperl 2.0)
import => 1 only works for import the sub's in the Perl namespace of the
current document. import => 0 only loads the file into memory, compiles it,
but doesn't do any import.
>
> Also, the call works if I import using import=>1 and just call it using
> [- foo -].
>
Yes, that's what import does.
> ... The calling mechanisms are obviously very different, it's
> just interesting to note that the simple Perl method of calling the [$
> sub $] seems to get confused with another subroutine of the same name,
> in a completely different directory subtree.
>
This maybe because of the imports. From where do you call these subroutines.
Re: Possible bug with EmbperlObject and [$ sub $]
Posted by Neil Gunton <ne...@nilspace.com>.
Gerald Richter wrote:
>
> > Gerald, I am having a problem with [$ sub $] and EmbperlObject. Let me
> > say first that this minimal case does in fact work as it should. There
> > is something inexplicable going on however in my (much larger) project.
> > If you look at this minimal case though I think you will see why I don't
> > think this is a problem with my code.
> >
>
> Neil, I didn't had the time to look thru that in detail, but I do it as soon
> as possible and let you know
Gerald,
Sorry about the repeated emails regarding this issue, but I continue to
play with the problem and have come up with more possible behavioral
clues. In my previous email, I said that Execute('#foo') worked.
However, I now discover that it ONLY works if [$ sub foo $] is in the
same file as the call to Execute('#foo'). When I move the [$ sub $]
definition out into a subroutines file (which is Executed to import the
subs) then I consistently get an error "Call to unknown Embperl macro
foo" on Execute('#foo'). This happens whatever form I use to import the
subroutines. I have tried the following combinations, to no avail:
[- Execute ({inputfile => 'macros.html', import => 0}) -]
[- Execute ({inputfile => 'macros.html', import => 1}) -]
[- Execute ({inputfile => 'macros.html', package => __PACKAGE__, import
=> 0}) -]
[- Execute ({inputfile => 'macros.html', package => __PACKAGE__, import
=> 1}) -]
Also, the call works if I import using import=>1 and just call it using
[- foo -].
I am increasingly flummoxed by all this, and starting to doubt my own
sanity here. I am looking closely at all my files to see if there is
something incredibly stupid that I am doing. It seems that every day I
am seeing a new behavior. I really hope that this is not something on my
end. But the previous example was reproducible even on my minimal test
server, and using Embperl rather than EmbperlObject. In other words,
this was simply using the following httpd.conf settings:
<VirtualHost 10.1.1.3:80>
ServerName test.dev.nilspace.com
SSLDisable
ServerAdmin neil@nilspace.com
DocumentRoot /www/nilspace/com/test
DirectoryIndex index.html
ErrorLog /www/nilspace/com/logs/error_log
TransferLog /www/nilspace/com/logs/access_log
PerlSetEnv EMBPERL_ESCMODE 3
PerlSetEnv EMBPERL_OPTIONS 16
PerlSetEnv EMBPERL_MAILHOST mail.nilspace.com
PerlSetEnv EMBPERL_OBJECT_BASE base.html
PerlSetEnv EMBPERL_DEBUG 66609149
</VirtualHost>
# Set EmbPerl handler for test directory
<Directory "/www/nilspace/com/test/">
<FilesMatch ".*\.(html)$">
SetHandler perl-script
PerlHandler HTML::Embperl
Options ExecCGI
</FilesMatch>
</Directory>
... and the following files:
index.html:
[- Execute ({inputfile => 'macros.html', import => 1}) -]
[- Execute ('#macro_test') # error: Call to unknown Embperl macro
macro_test -]
[- macro_test # ok -]
macros.html:
[$ sub macro_test $]
macro_test
[$ endsub $]
Once again, the following DOES work:
index.html:
[$ sub macro_test $]
macro_test
[$ endsub $]
[- Execute ('#macro_test') # ok -]
I am using 1.3.0.
HTH
-Neil
Re: Possible bug with EmbperlObject and [$ sub $]
Posted by Gerald Richter <ri...@ecos.de>.
> Gerald, I am having a problem with [$ sub $] and EmbperlObject. Let me
> say first that this minimal case does in fact work as it should. There
> is something inexplicable going on however in my (much larger) project.
> If you look at this minimal case though I think you will see why I don't
> think this is a problem with my code.
>
Neil, I didn't had the time to look thru that in detail, but I do it as soon
as possible and let you know
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------