> I am porting my source code archive browser presentation system, Safari,
> to be able to use Embperl. I like it: it took all of 10 lines of code to
> make a filter out of it. Safari now uses it for building it's "header"
> and "footer" html, and it can be used to process source files before
> display. <BRAG>Both uses are seen in this little test case:
>
> http://slaysys.com/saf_dev/-/embperl/index.epl
>
> Here, the output of the Embperl filter that processed index.epl is sent
> through a syntax highlighter:
>
> http://slaysys.com/saf_dev/s/embperl/index.epl
> </BRAG>
>
:-)
>
> 1. Silent death
>
> In so doing, I inserted some perl code containing '[*]' in a [! ... !]
> block. It was in the middle of several hundred lines, and I didn't notice
> it :-(.
>
> Anyway, I suddenly got "document contained no data", rather than some form
> of warning or error. Would it be possible to generate an error
> in this case?
>
Yes, of course there should be an error message. Embperl treats the [*] as
the start of a [* *], which is parsed out before anything else, so it's also
found inside other block. This is of course not the intened behaviour and
should be treated as a bug!
[* *] still experimental. I am currently start working on Embperl 2.0, for
which I do a complete rewrite of the parser and I will surly adress this
issue there...
> Just stick a '[*]' (quotes optional) in a [!...!] block and you should be
> able to reproduce it. Here's the backtrace, FWIW:
>
I try to fix at least this SIGSEGV soon.
>
> 2. Noisy death
>
> I still didn't see the problem after a reread, so I reached behind my seat
> for the shotgun and added "debug => 0xFFFF,"
Don't do this. At least you should _never_ set dbgCacheDisable = 32768,
because it does very inpreditable thing (I really have to remove it from
Embperl, it's very old and I haven't done anything on it for a long time)
> to
> HTML::Embperl::Execute( { ... } ) to see what might be going on.
>
> After removing enough chunks of code that I found my [*] and [[*]]ed it,
> Embperl then coughed up this:
>
> Usage: HTML::Embperl::logevalerr(r,sText) at
> /usr/lib/perl5/site_perl/5.005/i686-linux/HTML/Embperl.pm line 409.
>
That is because of the dbgCacheDisable = 32768, so set debug to 0x7fff and
this error will disapear.
>
> 3. CMS extensions
>
> On another topic, a couple of things that might make it nicer for
> embedding in Content Management Systems (a la Zope, or the Perlian
> Iajutsu (uses Wardley's toolkit, Jellybeans, Safari: building Perlish
> CMSs is quite popular right now). Please forgive me if these already
> exist and I missed them in the docs or the sources.
>
> A. Being able to flush the output half way through when an output_func is
> defined. When creating a really large bolus of HTML, or when about to
> embark on a time consuming query, it'd be nice to be able to send what's
> accumulated so far to the output_func. I looked at the source code with
> an eye toward patching, but this seemed a bit non trivial, and I'm not
> at all sure how it would interact with the commit/rollback code in the
> io module.
>
So you want to have output_func called multiple times for a document?
Currently it's only called after the end of the request and you are right
that's not total trivial to change this. If you send your output directly to
the browser, you could set optEarlyHttpHeader in your httpd.conf, then all
output is send directly to the browser, without buffering it.
> B. An easy way to export variables and functions to the package containing
> a page, so that I could export Safari's $context object in to a page's
> namespace easily without having to add code to the page. Currently I can
> import things in to the page and pass things in via @param, but that means
> all such pages need that extra little bit of boilerplate.
>
That's already on the todo list
> C. Access to %udat and %mdat from outside the pages.
>
Also on the todo list
> D. Some way of implementing inheritence on %mdat and perhaps %udat.
> The idea here being able to implement attribute inheritence that kicks
> in when a key doesn't exist in the hash. Whether this would be better
> done in Embperl.pm or EmbperlObject.pm, I haven't figured out.
>
That's a good idea. The question is how how should this inherence work?
Where in which %mdat/%udat should Embperl look next when a key doesn't
exist?
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
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]