>
>
> We're attempting to implement Embperl on an already-existing,
> relatively large
> website whose HTML writers/users number well over 400. We're
> finding that a
> large minority of documents already have the left square bracket
> followed by
> one of the special characters (+-*#$!) within them, obviously not
> intended to
> be interpreted as perl code.
>
> I'd like to suggest that Embperl be configurable (at worst during compile
> time, at best in apache run-time configuration files) with respect to what
> characters are used to mark the beginning and end of Embperl. For
> instance,
> I'd like to be able to use HTML comments instead of square brackets:
>
> <!--+ $a +-->
>
> I do see in the documentation that "Embperl does not use SGML
> comments (i.e.,
> <! ... !> or similar things) because some HTML editors can't
> create them, or
> it's much more complicated. Since every HTML editor takes (or
> should take) `['
> and `]' as normal text, there should be no problem." I suppose there are
> multiple sides to every problem, which speaks more to the idea
> that the code
> wrapper text should be configurable.
>
> Better still, would be the ability to configure from a single +,
> which is very
> common in existing HTML documents, to another character set: perhaps
> double-plus, perhaps EVAL-OUT.
>
> <!--EVAL-OUT $a EVAL-OUT-->
>
I agree that makeing the [+/-... -/+] configurable would be a good idea. The
problem is, that it isn't that easy. While it would not be much work to just
change the [ to any other character, things like <!-- are more compilcated,
because we have to search for a string, instead of a single char.
> Finally, what is the value with having the closing bracket be
> preceded by one
> of the special characters? Why not just have the opening
> character(s)? Is that
> not enough to determine how to deal with the ensuing perl code?
>
> <!--EVAL-OUT $a -->
>
In the above example that works, because you have a multi-char delimiter.
But [+ EVAL-OUT ], would be often misinterpreted, because the ] is very
common to perl code.
Makeing things configurable would solve all your problems, but I will not
make such a great change, which will touch a lot of code, before the 1.2
release version.
I put it on the TODO list for 1.3
Gerald
> Regards,
> Christian
>
> -----------------
> Christian Gilmore
> Senior Technical Staff Member
> AT&T Labs IP Technology, Florham Park
> [EMAIL PROTECTED]
> http://www.research.att.com/info/cgilmore
>
---------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internet - Infodatenbanken - Apache - Perl - mod_perl - Embperl
E-Mail: [EMAIL PROTECTED] Tel: +49-6133/925151
WWW: http://www.ecos.de Fax: +49-6133/925152
---------------------------------------------------------------
