Announcing the JSDO 4.1

Posted by Rob Straight on 01-Sep-2015 09:12

Progress has released version 4.1 of the JavaScript Data Object (JSDO).

Where To Find

             Navigate to https://github.com/CloudDataObject to access the various projects.

             A template using the JSDO is available when creating a new AppBuilder Hybrid Project (Hybrid app)

  • Note: Progress Rollbase Mobile 4.0 can use the JSDO integration with Telerik Kendo UI, which can be used from Telerik AppBuilder (a component of Telerik Platform).
What Has Changed
 
Here is a summary of the new features added:
  • Aliases were added for the following methods to be more consistent with non-ABL programming languages:
  • read() for fill()
  • update() for assign()
  • create() for add()
  • Aliases were also created for the following callbacks to be more consistent with non-ABL programming languages:
    • beforeRead for beforeFill
    • afterRead for afterFill
  • Support for iOSBasicAuthTimeout
    Previously if invalid login credentials cause the server to return a 401 (Unauthorized) code, the application code never receives the response and therefore cannot alert the user to the problem.To work around a bug in Apache Cordova, the progress.data.Session login() code now sets a timeout when it makes an asynchronous request using HTTP Basic authentication from an iOS device (the timeout will be set only under those conditions). The timeout allows the session manager to provide notification. The timeout defaults to 4 seconds but can be overridden by the programmer.
  • Added the ability for the JSDO to create a SQL query for Rollbase to retrieve a subset of records. This is similar to the ABL filter introduced in 4.0.

In addition a number of issues were also corrected:

  • Updated error messages for clearer understanding of the messages.
  • Fixed a problem in Rollbase when updating a new record that has not been saved.
  • Changed the return code of logging out from true to false when web server is not running.
  • Login using Form based authentication now works even if the preliminary response from the server is a status code 403 instead of the  expected 401.

All Replies

Posted by egarcia on 01-Sep-2015 10:56

Thank you for this information!

I have added a couple of wiki pages related to this:

Posted by Mike Fechner on 01-Sep-2015 11:18

Hi Edsel,
 
is the optimization regarding the number of count requests that we discussed here on the forum a few weeks ago included in that version?
Regards,
Mike
 
Von: egarcia [mailto:bounce-egarcia@community.progress.com]
Gesendet: Dienstag, 1. September 2015 17:58
An: TU.Mobile@community.progress.com
Betreff: RE: [Technical Users - Mobile] Announcing the JSDO 4.1
 
Reply by egarcia

Thank you for this information!

I have added a couple of wiki pages related to this:

Stop receiving emails on this subject.

Flag this post as spam/abuse.

Posted by egarcia on 01-Sep-2015 11:41

Hello Mike,

Release 4.1 of the JSDO was technically done by the time that we discussed the enhancement.

We will look into this enhancement in a future release.

Thanks,

Edsel

Posted by BrianWhite on 29-Oct-2015 10:23

Is there a Typescript definitions file for the JSDO?

Posted by Shelley Chase on 29-Oct-2015 11:27

Hi Brian,

We do not have one. There has not been any demand for TypeScript up to now.

It is pretty easy to define one yourself. We have one we have played with and could share it with you but it is NOT supported and will not be updated when the jsdo api changes.

The person with this is on vacation but can share it when they are back.

Thanks

-Shelley

Posted by egarcia on 02-Nov-2015 08:25

Hello Brian,

Thank you for your interest on a TypeScript Declaration file for the JSDO.

I have attached the version that we have played with to the Documents section:

https://community.progress.com/community_groups/mobile/m/documents/2621

I hope you find it useful.

Enjoy,

Edsel

Posted by BrianWhite on 04-Nov-2015 14:41

Edsel,

Thanks for this. I was able to get my "experiment" up and running through the JSDO, using Typescript.

I did vote for this back in July. I hope it becomes reality. (Kendo's paid-for package comes with the Typescript definitions file for its portion, by the way.)

Brian White

Posted by BrianWhite on 11-Nov-2015 10:57

Is there a way to add caclulated fields (or some sort of equivalent) to the JSDO on the client-side, or do we need to denormalize the data on the server-side?

Posted by egarcia on 11-Nov-2015 12:37

Hello Brian,

I think that depending on your needs, you can do this on the server side or on the client side.

On the server, something to keep in mind is that the temp-table definition in the Business Entity does not need to match exactly the definition of your actual table, you can add or remove fields and set the values appropriately.

On the client side, even though we do not have a calculated field feature in the JSDO, you can use Object.defineProperty() in JavaScript to obtain the result that you need.

Here is an example of adding a StateCountry field to the table reference for eCustomer:

       Object.defineProperty(jsdo.eCustomer, "StateCountry", {

           get: function () {

               return this.record.data.State + ", " + this.record.data.Country;

           }

       });

...

Here is an example on how you would access the property:

               console.log(jsdo.eCustomer.Name + " " + jsdo.eCustomer.StateCountry);

I hope this helps,

Edsel

Posted by Mike Fechner on 11-Nov-2015 15:05

Will this also work with the Kendo UI data source and the Kendo UI grid?

Posted by Mike Fechner on 11-Nov-2015 15:05

Will this also work with the Kendo UI data source and the Kendo UI grid?

Posted by BrianWhite on 11-Nov-2015 16:27

Edsel,

Thanks. I get the idea, but how do I do that from within a Typescript object? Typescript complains right after "Object." , then there are more errors after that.

Brian

Posted by Marian Edu on 12-Nov-2015 02:02

For Kendo data source you can add that in schema.model... ds.schema.model.total = function () { return this.qty * this.price; } only when using in grid for instance the column is total() not simply total. no idea though if doing that on a jsdo data source will break anything :(

Posted by BrianWhite on 12-Nov-2015 16:33

It took a little experimenting, but I finally have the property added to the JSDO, in the same place in the JSTableRef as the fields brought in from the calalog.json.

However, when I use the field in a LIstView template, I'm getting "Uncaught ReferenceError: KLASID is not defined" .

(KLASID was the proeprty I added.)  It is occurring at in n.ui.DataBoundWidget.extend.refresh

Any thoughts on how to resolve this? According the the Chrome debugger the property is there, and has a getter.

Brian White

Posted by egarcia on 13-Nov-2015 03:25

Hello Brian,

The error that you are seeing might be happening because the property is not defined for Kendo UI.

Please try adding it to the schema.

Here is an example showing how to do a relationship between two independent JSDO with the calculated property support in Kendo UI:

Example:

          schema: {

              model: {

                  StateName: function() {

                      var stateName;

                      var State = this.State;

                      var jsrecord = states.find(function(state) {

                          return state.data.State == State;

                      });

                      if (jsrecord)

                          return jsrecord.data.StateName;

                      else

                          return "";

                  }

              }

          },

You can run and look at the code at the following URL:

   oemobiledemo.progress.com/.../example024.html

The JSDO does not have support for calculated properties nor have support for extending the schema via Kendo UI. I added an issue to our tracking system to look into this in a future release.

Regarding TypeScript, you should be able to define the property in a subclass of TableRef.

Example:

class DSCustomer extends progress.data.JSTableRef {

   CustNum: number;

   Name: string;

   StateCountry: string;

}

I hope this helps,

Edsel

Posted by MTBOO on 02-Dec-2015 12:48

Hi,

Is this any method for the jsdo to pass back to the appserver custom filter parameters. We would like to be able to tell a business entity to perform no-fill on a given set of tables in a dataset. We have a Kendo grid using the jsdo as a data source but would like to be able to control the tables filled in the dataset via the request

Posted by egarcia on 02-Dec-2015 15:33

Hello,

I would like to get more detail on what you are trying to do.

However, at first look, it seems that you would just need to change the Business Entity to process the regular filter in a different way (control the tables filled).

This could be done using the JSON Filter Pattern (mappingType = JFP) or without specify mappingType so you would get the native JSON from the Kendo UI DataSource.

Another alternative would be to use your own mapping. This approach is not currently documented, however, you could do this with the latest version. If you need this functionality, please let us know so that this can be given the right priority.

The idea of the mappingType is that you can handle custom parameters.

(In general, in most cases you should be able to use mappingType = JFP).

Please see the following link for info on creating your own mappingType:

community.progress.com/.../69540

At this moment, there seems to be an issue with the server for the example mentioned in the post.

However, you should be able to access the source code and use your own backend.

Please let me know if you have questions.

I hope this helps.

Posted by MTBOO on 03-Dec-2015 06:14

Thanks for the info, will take a look at this. We are using a generic service interface for CRUD ops. We wanted to be able to define a datasource for Kendo UI (page with tabs). Each tab would be maintaining records for tables within ds. To reduce payload and to avoid making the Business Entity more granular, we could pass some info to the back end to allow filling of only tables we required.

Posted by egarcia on 03-Dec-2015 09:57

Thank you for the details.

Based on your description, it looks like the reason that you have multiple tables in the dataset is to implement the generic service.

Here are a couple of links on samples on how an alternative to implement a generic service:

- REST Generic Service for the JSDO:

 community.progress.com/.../2190

- WebSpeed Generic Service for the JSDO using OpenEdge 11.6:

 community.progress.com/.../2677

I hope this helps.

Posted by Mike Fechner on 04-Dec-2015 01:14

Hi Edsel,

"MTBOO"'s question is not the Visual Designer.

Assume a Business Entity built around a ProDataset with a Parent and two Child Tables.

Now you have a screen that would like to show the parent's (Person) records and a single child's (Address) records. in two related grids. The second child table is not relevant.

Demand is, that data for a batch of parents and all their addresses (first child only) if retrieved in a single REST call.

So

a) the 1'st JSDO needs to be able to send in the request that it needs to see Person (TableRef) and Address but not the second child. That requires the additional parameter, which to my understanding now can be solved by the custom mapping

b) we need two Kendo UI dataSource's for the JSDO's. The Person JSDO would only be special by fetching 2 out of 3 tabels from the backend. The second JSDO would need to be filled without a REST call by data that's already in the memory of the first JSDO.

So it will probably require digging deeper into the mysteries of the JDSO :-)

Posted by Mike Fechner on 04-Dec-2015 01:14

Hi Edsel,

"MTBOO"'s question is not the Visual Designer.

Assume a Business Entity built around a ProDataset with a Parent and two Child Tables.

Now you have a screen that would like to show the parent's (Person) records and a single child's (Address) records. in two related grids. The second child table is not relevant.

Demand is, that data for a batch of parents and all their addresses (first child only) if retrieved in a single REST call.

So

a) the 1'st JSDO needs to be able to send in the request that it needs to see Person (TableRef) and Address but not the second child. That requires the additional parameter, which to my understanding now can be solved by the custom mapping

b) we need two Kendo UI dataSource's for the JSDO's. The Person JSDO would only be special by fetching 2 out of 3 tabels from the backend. The second JSDO would need to be filled without a REST call by data that's already in the memory of the first JSDO.

So it will probably require digging deeper into the mysteries of the JDSO :-)

This thread is closed