refactor: ProgramCall.addParam to accept an object#139
refactor: ProgramCall.addParam to accept an object#139kadler merged 11 commits intoIBM:masterfrom abmusse:refactor-addParam
Conversation
|
There is an open proposal to add private methods to JS. https://github.com/tc39/proposal-private-methods It is currently a stage 3 candidate. In the future we could use this syntax instead of using |
|
Need to update unit ProgramCallUnit,js tests with this PR. |
- add internal functions to handle ds and data nodes
- addParam now accepts an object as a parameter - DS parameters are now in this format [name, type, value, options]
|
Functions who use This includes methods in the following classes:
|
kadler
left a comment
There was a problem hiding this comment.
I think this is a bit overly complicated. Basically, addData should do something like this:
if type is ds:
create "<ds>" node and set options accordingly
foreach field in ds fields:
xml += addData(field)
append "</ds>"
else:
create "<data>" node and set options accordingly
test/unit/ProgamCallUnit.js
Outdated
| ['', '10i0', 0], | ||
| ['', '10i0', 0], | ||
| ['', '36h', ''], | ||
| ['', '10A', ''], | ||
| ['', '1A', ''], | ||
| ['', '1A', ''], | ||
| ['', '10i0', 0], | ||
| ['', '10i0', 0], |
There was a problem hiding this comment.
Don't these all need to be objects now?
There was a problem hiding this comment.
Just to confirm we are on the same page.
How do we want DS to be defined?
Do we want DS to be an array of objects like shown here?
#107 (comment)
const errno = [
// fields can be defined using objects as well
// attributes are set on the object itself, not in a separate object
{name: 'bytes_provided', type:'10i0', setlen: 'rec2' },
{name: 'bytes_available', type: '10i0'},
// The value can be set on the object
{name: 'msgid', type: '7a', value: 'XXX0000'},
// we can also omit names in object format
{type: '1h'},
// Data structures can also be nested using object format
{name: 'message fields', type='ds', fields=[
// You can always mix and match object/array fields
['field1', '10i0'],
{name: 'field2', type:'10i0'}
]}
];If that is the case then yes we will need to change these to objects.
There was a problem hiding this comment.
yes, all data types should be objects. We can add shortcuts in v1.1 or later.
There was a problem hiding this comment.
Sorry, that example was before we talked about the problem for ds options. Thus, ds that need options must be objects, but I suggest we just stop supporting arrays for now as I just mentioned.
So something like this, instead:
const errno = {
name: "errno",
type: "ds",
setlen: "whatever",
fields: [
# fields here
]
}There was a problem hiding this comment.
but I suggest we just stop supporting arrays for now as I just mentioned.
Thanks! I agree all data types will just be objects for now. We can add shortcuts and options later.
I will also need to update the iPgm wrapper to create ds types as objects.
lib/ProgramCall.js
Outdated
| const nameNode = parameter.name ? ` name='${parameter.name}'` : ''; | ||
| this.xml += `<parm${nameNode}`; |
There was a problem hiding this comment.
Please do this like parameter.io and parameter.by are done below.
lib/ProgramCall.js
Outdated
| */ | ||
| __addData__(parameter = {}) { | ||
| // adding a data structure with data nodes | ||
| if (Array.isArray(parameter.value)) { |
There was a problem hiding this comment.
Why are we still handling arrays here? Let __addDsNodes__ handle this. Also, I thought we were switching to object-only anyway.
There was a problem hiding this comment.
Oh, never mind, I see that we are just checking if it's a ds or not. That should be done by checking parameter.type == 'ds' instead.
There was a problem hiding this comment.
Ok will update to check for parameter.type == 'ds'
lib/ProgramCall.js
Outdated
| * @param {string} value | ||
| * @param {object} options | ||
| */ | ||
| __addDataNode__(name, type, value, options) { |
There was a problem hiding this comment.
I don't see why this function is needed. It should be rolled in to __addData__.
lib/ProgramCall.js
Outdated
| * @param {array} ds | ||
| * @param {object} options | ||
| */ | ||
| __addDsNodes__(ds, options = {}) { |
There was a problem hiding this comment.
I don't see why this function is needed. It should be rolled in to __addData__.
test/unit/ProgamCallUnit.js
Outdated
| const { ProgramCall } = require('../../lib/itoolkit'); | ||
|
|
||
| // now in this format | ||
| // [name, type, value, options] |
There was a problem hiding this comment.
This is outdated with the latest changes
test/unit/ProgamCallUnit.js
Outdated
| }); | ||
|
|
||
| pgm.addParam(outBuf, { io: 'out' }); | ||
| pgm.addParam({ fields: outBuf, io: 'out', type: 'ds' }); |
There was a problem hiding this comment.
I'd prefer the fields go last; seems most sensible to me.
test/unit/ProgamCallUnit.js
Outdated
|
|
||
| pgm.addParam(params, { name: 'inds', by: 'val', io: 'both' }); | ||
| pgm.addParam({ | ||
| fields: params, type: 'ds', name: 'inds', by: 'val', io: 'both', |
There was a problem hiding this comment.
Prefer to see attribute order as name, then type, then the rest. fields probably makes most sense to go last
Resolves #107