You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by Gerald Richter <ri...@ecos.de> on 2000/12/19 14:21:26 UTC
Re: calling methods within EmbperlObject (was: Possible bug with EmbperlObject and [$ sub $])
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: 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