Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • A records dataproviders should be accessed through the record itself, which means first a record object needs to be retrieved before the dataproviders from such a record should be accessed.
    Example:

    Code Block
    var rec = foundset.getSelectedRecord();
    if (rec.phone_direct) plugins.mobile.call(rec.phone_direct);

    So try to avoid direct access of those variables, so use 'record.column' instead of just 'column' for the selected record in a form method.

  • new records pks always become UUID's values, while UUID are not required for pks for any data delivered by the server, the service solution would need to translate UUID's to local ids upon retrieval of new records.
    When using "push" from the mobile plugin, the service solution must return, for the newly created records, the server side pk; that means,
    the ws_create must return the pk as an object with uuid as key, pk as value, or if a bulk update is used in the service solution, ws_update must return a map object with uuid and server side pk, for each newly created rows; if nothing is returned, the client cannot change/delete the newly created rows, until a full sync is donethe object that performSync returns, that is an object with all uuid,pk mapping returned by ws_create methods;

  • only single pk are supported on entities. (no compound pk support)

  • no SQL support, everything has to happen via relations/foundset navigation from the provided root foundset by the service solution.

  • no calculation support. (yet, is planned)

  • only custom valuelists are supported, but application.setValueListItems is present

  • Be careful with the Form variables or Global variables names, prefix or post fix them with an nice value so that you don't have global variables named 'status' or 'document' these names must be avoided because they collide with the window.xxx object of the browser.

...