Projecting JSON

[mdavidovichHst]

I see you can set the setting %JSONINCLUDE = "none" to exclude from the projection.

It seems I get compilation errors if I don't set this setting for every property. Is there a way to default to %JSONINCLUDE = "none" when it's not set?

What about when a property is an object reference. What if you just want one or two pieces of data from that object reference and not the whole thing?

I assume that object has to be JSON enabled as well?

Ok lets say you HAVE to either include or exclude all the properties in the projection to make it work (I think that's the answer). What if one API call needs to send some information from the class and another needs to send a different set of data from the class?

I'm thinking this works is you start with REALLY good class design and you can be intentional about relationships and cardinality and not storing 100 properties on one persistent class. Is there a way to arrange the data as needed depending on the implementation without converting to a dynamic object and removing a bunch of data from the object?

I'm thinking our better bet is just to write implementation classes that just loop through the data and collect the properties we need and arranging them in the data model we need than simply projecting the tables.

Looking forward to thoughts!

[mdavidovichHst]

That said, the attraction to this, and what I'm exploring is a code first approach that produces to OpenAPI spec for documentation purposes. Can I still use this feature if I get a JSON object in another way (i.e. not using %pkg.isc.json.adaptor). Would I need a object.%ToJSON() or do I need to start with just a dynamic object? Where's my starting point in the doc for this approach?

[isc-tleavitt]

OpenAPI spec generation is dependent on use of %pkg.isc.json.adaptor. For best usability of OpenAPI generation I'd recommend looking at isc.ipm.js (see https://github.com/intersystems/isc-ipm-js/blob/main/docs/user-guide.md).

Use of OpenAPI generation without the package manager integration for it is supported but not yet documented. (Hoping to get to that documentation soonish.) isc.ipm.js has a good reference implementation though, at https://github.com/intersystems/isc-ipm-js/blob/main/cls/pkg/isc/ipm/js/openApiProcessor.cls#L25 .

[mdavidovichHst]

Ok sounds good. Hopefully with the use of custom mapping I can use as recommended.

[isc-tleavitt]

@mdavidovichHst it's good to hear from you again!

%pkg.isc.json.adaptor defines a parameter that can be overridden to avoid such compilation errors:

/// %JSONDEFAULTMAPPING may be set to 0 (default is 1) to suppress creation of the default JSON mapping for the object.
Parameter %JSONDEFAULTMAPPING As BOOLEAN = 1;

This means that you can JSON-enable a class without JSON-enabling every other registered class referenced by it directly or indirectly. It does, however, mean that you need to define custom JSON mappings (in XData blocks) to be able to do JSON import/export with just the subset of properties you're interested in.

I believe (but haven't tested/verified) that overriding the %JSONREFERENCE parameter from %pkg.isc.json.adaptor and setting it to something other than OBJECT might also prevent the issue, but that might not be what you really want.

[isc-tleavitt]

@mdavidovichHst you should be extending %pkg.isc.json.adaptor in this case. There's a different XML namespace for %pkg.isc.json.adaptor than for %JSON.Adaptor (http://www.intersystems.com/_pkg/isc/json/jsonmapping) - see examples like https://github.com/intersystems/isc-json/blob/main/docs/user-guide.md#including-row-ids-in-json-projection-of-persistent-classes .

There's no way to have a superclass automatically apply to a whole package that I'm aware of, but often I'll end up extending %pkg.isc.rest.model.adaptor (for example) and defining behavior common to all relevant models in the application. All persistent JSON-enabled types in the application then extend this subclass.

GetProxyColumnList should work without JSON-enabling properties that aren't projected to JSON (assuming you're using %pkg.isc.json.adaptor). If it somehow doesn't, that's a bug.

[mdavidovichHst]

Ok let me review this and get back to you.

I did extend %pkg.isc.json.adaptor and then added my Xdata block in the class after setting Parameter %JSONDEFAULTMAPPING = 0. It didn't compile until I added %JSON.Adaptor but I'll take a look at the documentation links you've provided and see where I may have blundered.

Thanks as always @isc-tleavitt !!

[isc-tleavitt]

@mdavidovichHst happy to help, as always! If you're still stuck we can try to set up a call. (You have my email. That said, I do appreciate having these conversations in the open as a default mode.)

[mdavidovichHst]

@isc-tleavitt I think I'm very close to having a working example based on the demo.

I'm making the call and getting a 200 response but an empty object {}

I see in %pkg.isc.rest.authentication.platformUser %JSONExport() is called without a parameter. When you define custom JSON mappings how do you tell %JSONExport() which one to use?

Right now I have one, but I could see us having multiple mappings to support different APIs.

[isc-tleavitt]

@mdavidovichHst see https://github.com/intersystems/isc-rest/blob/main/docs/user-guide.md#pkgiscrestmodeladaptor - %pkg.isc.rest.model.adaptor (actually proxy I think, technically) defines an overridable parameter you can use for that:

JSONMAPPING (optional): Set this to the name of a JSON mapping XData block. Defaults to empty (the class's default JSON mapping). Look at Using XData Mapping Blocks to understand how JSON mapping XData blocks work.

Generally we'll differentiate between different representations (JSON mappings) of the same resource by giving them the same RESOURCENAME and different values for MEDIATYPE. (And obviously only one representation extends adaptor; others (if not all) need to extend proxy.)