http://www.udev.info
Mail/Login: Password : forgot my password!
[UPDATE MODE]
Back

Enhancing GHANweb with $encode and $decode

Direct link http://www.udev.info/uniface/enhancing-ghanweb-with-$encode-and-$decode
Written by -GHAN- // Tags: encode decode ghanweb uniface json html md5

With $encode and $decode two new function showed up in Uniface 9.4. They offer a various bunch of possibilities for Uniface and especially for then GHANweb project.

What we want to do with these functions is to enrich the dialog between Uniface and the HTML frontend.

First lets find a bottleneck

If you followed the project and my contributions then you will have discovered, that I put my own content into $webinfo("output"). This is only a string which directly is tossed to the cgi interface. We have the option to put everthing into that output and are done. But as we walk into the realm of JavaScript and JSON, then we soon will get a problem to make it a structure.
Let's say, we have a template to be loaded and in addition, we need a return code, in order to figure, if we succeeded or failed. What do we do? Do we deliver a complete HTML back or just the return code?
Or another example is where we edit an occurence and want to save. The store fails and we could deliver the reason in an nice return code and error message. BUT unfortunately, we only have one string and need to decide.
What we need, is to deliver a structure, that is native to the frontend. This structure is called JSON. Of course this is possible to build without $encode. But you will have to escape all the content in order not to break the JSON notation. $encode will help us out and make this pretty easy!

Responding in JavaScript objects (JSON) using $encode

Our goal is to produce a comprehensive reply to the HTML frontend in order to deliver a fitting feedback to the user. I found the following values to be good:
- a numeric return code (rc)
- a token so the request can be identified (token)
- a data field (message)
Any other content will be optional. But these two besides the token should be mandatory in every feedback. If we fail in our action, then the return code be negative. The error will be found in then message. Same goes with a positive feedback saying rc=0, "Data has been saved!".
The JSON object would be looking like this:
JSON String SOURCE CODE
Sorry- ... please log-in or register to get this!

There is no vodoo in building strings looking like that, I agree :) But things are a bit more complicated as they seem.
While we use messages for examples lets consider the following message:

Error: The data with the key "!KEY!" couldn't be saved- aborting!

The problem comes with the " and some other characters, which can destroy the simple JSON string. What we need is to escape theese things, which again used to be a lame job. But today we pay this problem a smile and encode it to something usefull.

We will take the functions $encode and $decode to do the job. They offer a wide spectrum of encoding. Besides HEX there is another mode called URL. This will URLENCODE the data to something that not directly will spoil our JSON string :) And this looks like this:
$encode(HEX) and $encode(URL) SOURCE CODE
Sorry- ... please log-in or register to get this!

As you can see, the URL mode almost does a nice job but fails to quote the characters " and ' as they dont get translated to something that wont spoil the string! So what we need is to transform the string into HEX and decode it in the front end.

This overhead is maybe not that bad, but surely not necessary. I decided to play that ball to Compuware!

Make a WISH!

Yepp ... so I did! I would like to have another mode called "HEX_STRING" which does the same as "HEX" but puts a "%" in front of every byte!
$encode(HEX_STRING,string) SOURCE CODE
Sorry- ... please log-in or register to get this!

With that, we could easy grab the string and decode it with basic JavaScript functions and no additional stuff using the decodeURIComponent() method. Please support the wish!

Comments

881 view(s) / 2012-02-06 16:02:03 / LAST UPDATED: 2012-03-01 14:14:37