Hi Gerald,
I am still having problems with a scenario which I will outline in
detail below. I hope this functionality is not too much of a pain to
incorporate. I have tried to supply a minimal case.
Assume the following in the httpd.conf:
SetHandler perl-script
PerlHandler HTML::EmbperlObject
Options ExecCGI
DirectoryIndex base.html
PerlSetEnv EMBPERL_ESCMODE 3
PerlSetEnv EMBPERL_OPTIONS 16
PerlSetEnv EMBPERL_OBJECT_BASE base.html
And the following files (stripped of all extraneous HTML - the contents
of each file are indented):
/base.html
[- Execute ('subs.html') -]
/subs.html
subs
/foo/subs.html
[- Execute ('../subs.html') -]
<P>
foo/subs
/foo/bar/subs.html
[- Execute ('../subs.html') -]
<P>
foo/bar/subs
Ok, now if you point your browser at / you will see:
subs
If you go to /foo/ then you should see:
subs
foo/subs
And if you go to /foo/bar/ then you should get:
subs
foo/subs
foo/bar/subs
However, it the latter two examples will fail (in my setup). I believe
it is due to the use of the relative '../subs.html' path in the
Execute() call. I confirmed this by adding a couple of symbolic links
thus:
ln -s .. /foo/foo..
ln -s .. /foo/bar/bar..
This places a uniquely named link to the parent directory (..) in each
of the directories /foo/ and /foo/bar/.
Now if I change files as follows:
/foo/subs.html
[- Execute ('foo../subs.html') -]
<P>
foo/subs
/foo/bar/subs.html
[- Execute ('bar../subs.html') -]
<P>
foo/bar/subs
Now it works. The output is as expected.
So, there appears to be a problem with the use of relative paths - but,
though I am not familiar with the code, I would surmise that it is
rather a problem with duplicate filenames in the internal cache. Since
'../subs.html' will be called more than once during any session, it is
important that there be some way of uniquely identifying references to
relative filenames internally (perhaps by using the fully qualified
path?).
Having said all that, I hope I'm not doing something really stupid. I
think the minimal example outlined above is a useful pattern which
occurs frequently in object-oriented design, and it would be great if
EmbPerl could handle it without the need for special relative symbolic
links.
The other issue can be illustrated by using the same example, the only
difference being that we remove the file /foo/subs.html. So this means
that if we go to /foo/bar/ then the /foo/bar/subs.html file will try to
execute the "parent" subs.html in the immediate parent directory, but
it's not there. Currently, it seems to fail. It would be nice if the
EmbPerl Execute() function could recognise that it needs to trace back
up the directory tree and find the next valid instance of the file,
which in this case is in /subs.html.
Again, this is quite a common OO pattern and it would make directories
cleaner by ensuring we didn't need to put almost-empty proxies at every
level of the directory tree.
I hope this is clear, and again I hope I haven't missed some glaring
feature which makes it all work. If there's anything else that I can
clarify then I would be more than glad to oblige.
One last thing: I noticed some weirdness with EMBPERL_ESCMODE in the
latest version. If I set it to zero then pages tend to hang at the very
end for a few seconds, before finally completing as normal. If you hit
the "stop" button on the (Netscape) browser then you get the usual
"transmission interrupted" message inserted at the bottom of the page. I
note that if you change the EMBPERL_ESCMODE in httpd.conf to 3 then
everything works normally. I can achieve the effect I want (for $escmode
to be 0) by setting it explicitly in the code, in those pages which are
sensitive to the value. Is this a known problem? It also seems to happen
on pages which aren't using EmbperlObject, for what it's worth.
Anyway, I hope all this makes sense!
Thanks
-Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
