Re: Writing XML from RPGLE -- RPG400-L

powerEXT Core does most of it all …

First of all, powerEXT Core is based on CGIDEV2 and shares I/O buffers with
the underlying CGIDEV2 service program (shares 15 subprocedures with
CGIDEV2) so it is possible to mix CGIDEV2 and powerEXT Core subprocedures
by including the copy books from both. It is however a special version of
CGIDEV2 but it should be compatible by recompiling in most cases. The
CGIDEV2 service program has however also been renamed so it doesn’t
interfere with existing plain CGIDEV2 programs running on IBM’s or
Giovanni’s version.

powerEXT Template support uses the CGIDEV2 template subprocedures (the
difference is that there is no need for GetHtmlIfs() since the file name is
specified in each call and the system keeps track of which template files
is already loaded):

You may ask why I have these different template delimited types, but I do
programs that generate programs that generates programs

echoAsp(file:section); // asp section and variable encoding

Typical powerExt ASP based (in this case JSON) template:



{header : "<% pxGridHeading %>" <% pxRender %>

,width : <% pxGridWidth %>

,dataIndex : "<% pxField %>"

,align : "<% pxGridAlign %>"

,sortable : <% pxGridSort %>

}

echoCgi(file:section); // powerExt special section and variable encoding

Typical powerExt based (in this case JSON) template that doesn’t interfere
with the ASP encoding (the above template is generated based on this
template):

<powerEXT>alpha

// ------------------------------------------------------------------

// Field Name: /%pxField%/ /%pxDescription%/ Template: alpha

// ------------------------------------------------------------------



{header : "<% pxGridHeading %>" <% pxRender %>

,width : <% pxGridWidth %>

,dataIndex : "<% pxField %>"

,align : "<% pxGridAlign %>"

,sortable : <% pxGridSort %>

}

echoCgiDev2(file:section:[delimiters]); CGIDEV2 standard section and
variable encoding

Node support:

Any powerEXT Node support can be mixed with traditional CGIDEV2 like
template support. Node support will however automatically encode special
characters in data according to the rules of the node type. Many will
disregard the need for encoding of special characters in hierarchical data
structures but it will eventually bring a system down if you don’t.
Especially JSON is very none forgiving and since JSON goes into javascript
objects a system will come to a complete halt by a single none encoded
character.

powerEXT Core has various encoding subprocedures that covers HTML, XML,
JSON, CSV, javascript and RPG and has also decoders for XML and JSON and
thereby build transformers for decoding/encoding between various data
formats. In nonpublic procedures I can even convert EDIfact and X12 from/to
XML and re-decode data between the formats.

Node support will also keep track of the hierarchy and indent the generated
code for readability in any text based tools. If a compressed format is
needed to save bytes indent can be turned off.

Writing inline HTML with node support:

htmlNode(elementname:[attributes]:[data]);

htmlEndNode([elementname]);

Writing inline XML with node support:

xmlNode(elementname:[attributes]:[data]);

xmlEndNode([elementname]);

http://powerExt.com/xmlwrite.txt

http://powerExt.com/CustomersXml.txt

Generation inline RPG Xml Nodes based on XML template/example:

http://powerExt.com/wbrxmlinvoice.txt

http://powerExt.com/wbrxmlrpg.txt

**WARNING ** this following is old mixed code with a lot of BL and it work
on existing in-house files and with all due respect for Birgitta’s SQL
approach I would like to see the SQL statement that can do the same ;-)

http://powerExt.com/wbrxmli.txt

Writing inline JSON with node support:

jsonNode(type:[elementname]:[data]);

jsonEndNode([type]);

http://powerExt.com/jsonwrite.txt

http://powerExt.com/CustomersJson.txt

Writing inline CSV with node support:

csvDelimiter(delimiter); //set the delimiter

csvNode(data);

csvEndNode();

Reading XML:

powerEXT has its own xmlReader that works very similar to XML-SAX without
the need to have d-specs that defines the XML tree and has also far more
supporting options such as reading HTML (bypassing <script> and <style>
sections) and (in combination with the IFS writing subprocedures) is able
to chop up XML batches in sections (such as separating a number of invoices
into a IFS file per invoice).

Besides that the xmlReader works from V5R2M0+ and supports XML name spaces.

xmlReader();

http://powerExt.com/xmlread.txt

Reading a simple JSON object without arrays from string:

jsonToField(jsonAddr:jsonSize:variableName:[defaultValue]);

http://powerExt.com/jsonreadsimple.txt

Reading complex JSON object:

Convert JSON to XML and read it as XML:

jsonToXml(jsonAddr:jsonSize);

http://powerExt.com/CustomersJsonXml.txt

http://powerExt.com/jsonread.txt

Reading CSV:

Same procedure as JSON …

csvToXml(csvAddr:csvSize:fieldDelimiter:alphaStringDelimiter);

Now, there is many ways to Rome. One of them is just powerEXT Core that in
style tries to bring simplicity into the complex equation (by having
similar work models to different hierarchical data structures) and in the
same time provide a service program that is able to provide a coherent
approach between different data formats and transport routes (handling
HTTP/Apache server through CGIDEV2, HTTP Client through Scott’s HTTPAPI,
handling IFS files through the QC2LE procedures and handling FTP/SFTP and
MAIL transfers in various ways).

The reality is that people choses what is closest to their own programming
style and there is no “one size fits all”.

On Fri, Aug 22, 2014 at 7:16 AM, John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

On Fri, Aug 22, 2014 at 12:27 AM, Bradley Stone <bvstone@xxxxxxxxx> wrote:

Hi, Vern.

I checked out a sample of it and it looks good like it would work, and
makes sense.

But will it do JSON, or <insert new data format here>?

That's the beauty of something like CGIDEV2 or our eRPG SDK. It's not
limited to just one format like XML. It's a very high level template
system that you can really do anything you want.

But his current concern is specifically XML (Excel .xlsx files), so
support for other formats is a pretty low priority for him. He's
already enthusiastically endorsed CGIDEV2 countless times on this
list, including the message you just quoted from him.

I'd love to work with you to put together examples of an application

where

you (or someone else) use XMLi and I use the eRPG SDK.

It sounds like Vern is still in the relatively early stages of working
with XMLi. It probably wouldn't be a "fair fight". ;)

Maybe someone else (or I could as well) provide a CGIDEV2 example. Just

so

we can show users practical comparisons.

Vern is probably way more experienced with CGIDEV2 than with XMLi. I
don't recall anyone on this list chiming in as an XMLi expert (which
could mean I just missed it, or they are lurking), but Jon and Susan
did this intro piece on it:

http://www.ibmsystemsmag.com/ibmi/developer/rpg/xmli/

And apparently there are plenty of examples in the XMLi bundle itself.
(No, I have not checked them out personally.)

John Y.
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.