I'm experimenting with using the JSDO to communicate with a business entity I've setup on my PASOE instance. I'm not using any sort of fancy frameworks - just plain old HTML with the JSDO included as JavaScript. The business entity is based on a single table. It's not customized at all - just what gets automatically generated with the wizard in 11.7.4.
In doing so, I'm seeing that the actual behavior of the JSDO doesn't square up with the documentation.
For instance, the documentation says you can do a fill() and then access the resulting data by accessing the temp-table name as a property of the jsdo object.
For example, if your jsdo reference were myJSDO, and the temp-table is ttWebUser, then the docs say you can access myJSDO.ttWebUser.foreach().
I'm getting data back from my BE, but the jsdo object doesn't have a ttWebUser property.
Question 1: Is there any special trick to getting the jsdo to put the data into a property named like your temp table?
The jsdo object does have a foreach property, but it doesn't come back with a single table record for each iteration. Instead it returns a "JSRecord" object that then has a "data" property, which then has my dataset in it, and my dataset has my temp-table and its data. It has the whole thing. On each iteration. If I console.log() the record that comes into the foreach function, it's showing this:
Question 2: What in the world is going on here? Why would a foreach return the entire dataset? Why would the resulting JSRecord object not have fields defined in it like the documentation says it does?
Does anyone have a really simple example of using a jsdo with plain old JavaScript to access a BE's methods? Maybe a tutorial out there that doesn't involve mobile development or Kendo?
After some discussion with Edsel, I was able to get past this problem.
Looking at my .json catalog file, the Business Entity did not have a schema listed. The element highlighted below was not there:
Edsel asked me to look at the top of my BE's .cls file at this annotation:
@progress.service.resource FILE(name="BEWebUser", URI="/BEWebUser", schemaName="dsWebUser", schemaFile="bewebuser.i").
Even though it's in my propath, adding the full relative path within my project was needed:
@progress.service.resource FILE(name="BEWebUser", URI="/BEWebUser", schemaName="dsWebUser", schemaFile="Ingrid/PASOEContent/WEB-INF/openedge/bewebuser.i").
Once I fixed that and edited my defined service that included this BE. (Just open and save - no changes needed) It began to correctly include "schema" in the catalog, and a fill() call resulted in the jsdo object having a ttWebUser property that I can access.
Best I can tell, this problem must have happened when I moved my BE from the "appserver" directory to the "openedge" directory in my PAS project.
One problem down. Thanks Edsel!
The problem turned out to be that my service catalog, the .json file, did not have a "schema" section in it for my BE.
In my BE, at the top of the file, my annotation looked like this:
@progress.service.resource FILE(name="BEWebUser", URI="/BEWebUser", schemaName="dsWebUser", schemaFile="bewebuser.i").
But it needed to look like this:
@progress.service.resource FILE(name="BEWebUser", URI="/BEWebUser", schemaName="dsWebUser", schemaFile="Ingrid/PASOEContent/WEB-INF/openedge/bewebuser.i").
Once I fixed it and then opened and saved the service definition, it deployed a new catalog that included the "schema" element:
Once that was in place, the JSDO began to act correctly as documented.
Thanks Edsel!
Hello,
> Question 1: Is there any special trick to getting the jsdo to put the data into a property named like your temp
> table?
No, there is no special trick. It should work just fine with BEs and catalog files generated with PDSOE.
The BEs use a prescriptive approach.
> Question 2: What in the world is going on here? Why would a foreach return the entire dataset? Why would
> the resulting JSRecord object not have fields defined in it like the documentation says it does?
Could you share the signature of your READ method and the corresponding catalog .json file?
What version of the JSDO are you using?
Where are you downloading the JSDO from?
Are you downloading it from npm ( www.npmjs.com/.../jsdo-core )?
Older versions of the JSDO used jQuery Promises and the promises used a signature like this "(jsdo, success, request)".
Recent version of the JSDO use JS (ES6) Promises and the promises use (object) as the signature.
(The new version has a mode that allows usage of jQuery Promises if desired.)
> Does anyone have a really simple example of using a jsdo with plain old JavaScript to access a BE's
> methods? Maybe a tutorial out there that doesn't involve mobile development or Kendo?
Here are some examples:
- oemobiledemo.progress.com/.../example001.html (JavaScript Promises)
- oemobiledemo.progress.com/.../example013.html (jQuery Promises)
The wiki in GitHub also has an example:
- github.com/.../Using-the-JSDO-component-with-plain-HTML-and-JavaScript
I hope this helps.
After some discussion with Edsel, I was able to get past this problem.
Looking at my .json catalog file, the Business Entity did not have a schema listed. The element highlighted below was not there:
Edsel asked me to look at the top of my BE's .cls file at this annotation:
@progress.service.resource FILE(name="BEWebUser", URI="/BEWebUser", schemaName="dsWebUser", schemaFile="bewebuser.i").
Even though it's in my propath, adding the full relative path within my project was needed:
@progress.service.resource FILE(name="BEWebUser", URI="/BEWebUser", schemaName="dsWebUser", schemaFile="Ingrid/PASOEContent/WEB-INF/openedge/bewebuser.i").
Once I fixed that and edited my defined service that included this BE. (Just open and save - no changes needed) It began to correctly include "schema" in the catalog, and a fill() call resulted in the jsdo object having a ttWebUser property that I can access.
Best I can tell, this problem must have happened when I moved my BE from the "appserver" directory to the "openedge" directory in my PAS project.
One problem down. Thanks Edsel!
The problem turned out to be that my service catalog, the .json file, did not have a "schema" section in it for my BE.
In my BE, at the top of the file, my annotation looked like this:
@progress.service.resource FILE(name="BEWebUser", URI="/BEWebUser", schemaName="dsWebUser", schemaFile="bewebuser.i").
But it needed to look like this:
@progress.service.resource FILE(name="BEWebUser", URI="/BEWebUser", schemaName="dsWebUser", schemaFile="Ingrid/PASOEContent/WEB-INF/openedge/bewebuser.i").
Once I fixed it and then opened and saved the service definition, it deployed a new catalog that included the "schema" element:
Once that was in place, the JSDO began to act correctly as documented.
Thanks Edsel!
Peter, what's a "CVP forum"?