This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
RE: BRL reader problem.
In the eval based brl (BRL Classic) BRLReaderString was called 3 times,
returning "", "lorem" and "".
Servlet based BRL returns BRL.emptyForm, "(brl ]lorem" and ")]", where I
am not sure why the string length is 3, but only 2 characters are
returned, in the last string. That's what I meant about the return
values.
Dan Stanger
Eaton Vance Management
Two International Place
Boston, MA 02110
Mobile: 617 646 9682
Office: 617 672 8261
-----Original Message-----
From: Per Bothner [mailto:per@bothner.com]
Sent: Tuesday, August 25, 2009 2:39 PM
To: Dan Stanger
Cc: kawa@sources.redhat.com
Subject: Re: BRL reader problem.
On 08/25/2009 11:22 AM, Dan Stanger wrote:
> Thank you for the patch.
> Other than the return type (FString) vs java.lang.String, would you
> expect the return values for old eval based BRLReaderString to be
> different than the current BRLReaderString ?
Well, there is the hack in that the current SVN version returns
an UnescapedData rather than a String. That might not be what you
want. An UnescapedData is like a string, but special characters
(such as '<') are written verbatim, even when the output is
sent to an XML/HTML formatter.
Note that UnescapedData does implement CharSequence, so it is
considered a Scheme string.
BRL Classic doesn't use an XMLPrinter, so XML escaping is done
by hand (or using utility functions), which can be more risky
(injection attacks) and possibly inconvenient. Hence UnescapedData
isn't needed. KRL mode does use an XMLPrinter, and instead
text in ]xxx[ becomes UnescapedData, while a regular string "xxx"
is a String (and so automatically gets XML escaping).
I think this is a useful convenition, but of course it isn't
fully compatible with BRL classic.
BTW I am thinking about adding support for XML syntax literals.
I'm leaning towards using the dispatch prefix #x< .... ># as in:
#x<span id ="foo">Span with some <b>bold</b> text.</span>#
I'd add escaping:
#x<p>The result is: [result]</p>#
Something similar would allow string interpolation and formatting:
#"The result: [~5d result]"#
(This would also be the hook for string localization a la gettext.)
(All other things being equal, I would prefer curly braces rather than
square brackets for vanilla Kawa, but square brackets would make more
sense for BRL.)
(These features are on my wishlist; it's nowhere top of the list!)
--
--Per Bothner
per@bothner.com http://per.bothner.com/