I have multi-line text I need to transport from the server to the EWB
application. This means it can have CR/LF sequences, and that breaks
the JSON format. No problem, I just convert the CR/LF to \n in the
string, as part of the escaping. So now they are on the EWB client, and
TReader reads them into the various object properties. I was about to
either do a manual conversion on every object, or add get/set to every
property, when I thought what a lot of work that was, given that
TReader and TWriter are the better places to fix this once and for all.

However, there is no virtual mechanism to modify the GetString reader
and post-process it. I wonder though if there is a RTTI similar
mechanism to iterate the strings, though that makes me ponder how easy
it would be to get the JSON for the object later...

Anyone else come up with a good way to handle this?

Hmm, looking at the source shows
 AReader.AddFixup(Self,TempName,AReader.ReadString);

Could I modify the reader for specific properties? Hmm, how about
writing... No, that's not relevant I don't think - it isn't a method as
the last parameter.

--

Matthew Jones

Matthew,

<< I have multi-line text I need to transport from the server to the EWB application. This means it can have CR/LF sequences, and that breaks the JSON format. No problem, I just convert the CR/LF to \n in the string, as part of the escaping. >>

Nope - do what EWB does and convert them into their Unicode escape sequence.  Using \n, \r, etc. can result in ambiguous interpretations of what is a LF, depending upon the browser/client platform.  Using Unicode escape sequences avoids any ambiguity at all.

Plus, this is supported out-of-the-box with EWB web server modules and the TEWBJSONWriter component:

http://www.elevatesoft.com/manual?action=viewmethod&id=ewb2mod&product=rsdelphi&version=XE&comp=TEWBJSONWriter&method=StringValue

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> << I have multi-line text I need to transport from the server to the
> EWB application. This means it can have CR/LF sequences, and that
> breaks the JSON format. No problem, I just convert the CR/LF to \n in
> the string, as part of the escaping. >>
>
> Nope - do what EWB does and convert them into their Unicode escape
> sequence.  Using \n, \r, etc. can result in ambiguous interpretations
> of what is a LF, depending upon the browser/client platform.  Using
> Unicode escape sequences avoids any ambiguity at all.
>
> Plus, this is supported out-of-the-box with EWB web server modules
> and the TEWBJSONWriter component:

Hmm, it appears the source to these components is not available,
despite having a source directory. (XE2 download - took me a while to
realise it was a separate download!).

I can't see any special handling in the WebBuilder library, and a quick
test putting some new lines into a multi-line edit and assigning it to
a string property, and then using TWriter.Create(dtfISO8601); to output
the TPersistent descendent gives me invalid JSON.

I shall try to find more on the Unicode escape, but unless
TReader/TWriter do it as standard, it isn't going to fix the underlying
issue. Hmm, I've checked TParser.ParseString and it does the reading
part of the encoding, which fits with your module writer doing it. So
it is the writing part of the WebBuilder code that needs to be modified
to be able to generate valid JSON that can be round-tripped within
itself.

--

Matthew Jones

Matthew,

<< I can't see any special handling in the WebBuilder library, and a quick test putting some new lines into a multi-line edit and assigning it to a string property, and then using TWriter.Create(dtfISO8601); to output the TPersistent descendent gives me invalid JSON. >>

Yeah, we already had this conversation:

http://www.elevatesoft.com/forums?action=view&category=ewb&id=ewb_general&page=1&msg=9502#9502

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Yeah, we already had this conversation:

Ah, right, yes. I was going to say it was a different issue, but of
course it is the same and the fix isn't in the current release, which
is what I'm using on the VM I'm developing this project on.

Looking forward to the update to come then - and the command line
compiler working again! 8-)

--

Matthew Jones