Hi Neil,
the setup you outlined below should work as you expected with 1.3b6.
To give me a chance to track down why it doesn't please set EMBPERL_DEBUG to
66609149 and send me the embperl.log file of your request and the output you
see at the browser.
The issue with ESCMODE = 0 is that, in 1.3b6, if ESCMODE is 0, no crlf is
appended to the page, so it is possible to output binary data. Try to add a
newline to the end of your source, does it work then with ESCMODE = 0 ?
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 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
----- Original Message -----
From: "Neil Gunton" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, November 01, 2000 12:35 AM
Subject: EmbperlObject in 1.3b6
> 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]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
