Paul,
When you use the DATA-INTO %PARSER() BIF, there's a 2nd parameter where
you can specify options. For YAJLINTO, these options are passed in the
form of a JSON document that can affect how YAJLINTO operates. There
aren't many options, here, and I think it's probably unusual that
someone would use them.
All options are optional, you only need to pass the ones you want to
change.
%PARSER( 'YAJLINTO'
: '{ +
"value_true": "1", +
"value_false": "0", +
"value_null": "*NULL", +
"document_name": "whatever" +
}');
The value_true/value_false relate to JSON boolean fields. By default,
it maps "1" for true, and "0" for false because it's assumed that a JSON
boolean would be mapped to an RPG indicator. But you can override that
to any character string you like.
value_null is the value mapped when a JSON field is set to the special
value of null. RPG does not allow DATA-INTO to set a field's %NULLIND
(null indicator) so all we can do is map a value to a field. It
defaults to *NULL to indicate a field was null. In my experience, null
fields are very unusual in business documents.. but if this does come
up, you can map it to any character string you like.
document_node is a name assigned to the document node (outermost
element) of a JSON document. By default, the document node is never
assigned a name. (Indeed, the JSON standard has no provision for
assigning a name to the outermost node.) This option is a workaround
for a problem with DATA-INTO's "path" option. Since DATA-INTO is based
on the older XML-INTO tool, and XML always gives names to all XML tags,
the "path" option only works when an element has a name... since
document nodes never have a name in JSON, the "path" option doesn't
really work in DATA-INTO. This option allows you to work around that
by giving a name to the outermost element so that it'll work with
"path". Frankly, this is a kludge... the "right" fix for this is to
fix DATA-INTO so that an element doesn't need to have a name, but that
requires a change from IBM (not me)...
For example, say you have this document:
{
"name": "XX",
... other fields here...
"address": {
... other fields here...
"postal": "12345"
}
}
If you only wanted the "postal" field and didn't want to read the whole
document, you could do:
%DATA(myJSON: 'path=doc/address/postal') %PARSER('YAJLINTO': '{
"document_name": "doc" }')
The problem is that "address" is inside some { } characters that have no
name assigned to them. You can't do a path=/address/postal because
DATA-INTO doesn't understand how to map an unnamed element. So
"document_name" assigns the name "doc" to that outermost element,
allowing you to do path=doc/address/postal
The "right" fix to that would be to change "path", since this is
perfectly normal in JSON... I need to file a PMR with IBM to get that
fixed.
-SK
On 6/12/2018 10:19 AM, Steinmetz, Paul wrote:
I downloaded the latest YAJL.zip file from http://www.scottklement.com/yajl/.
Restored the objects form the YAJLLIB72.savf.
I'm looking for the details of the 05/17/2018 update.
Note: Updated May 17, 2018 added additional options to YAJLINTO.
Any one from the group know what the additional options added to YAJLINTO are?
Thank You
_____
Paul Steinmetz
IBM i Systems Administrator
Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071
610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home
psteinmetz@xxxxxxxxxx
http://www.pencor.com/
midrange.com
