Regards / Med Venlig Hilsen
Thomas Hansen Director ___________________________________ appSolutions a|s
Hi Thomas, for creating a simple master-detail app, I found this example to be helpful: http://help.gotiggr.com/getting-started/building-clickable-list-mobile-app-with-html5-local-storage. That example uses a local variable to pass the id to the details page. The key points in that example are:
- list items include a hidden label ("tag") which is the id of the record
- there are two events for clicking a list item: 1) set the local variable to be the clicked item's tag, 2) change the page
- the detail page has a Page Show event for invoking the appropriate service (I first tried Load event but then I got the same data every time)
I was also thinking of using the existing JSDO dataset but I have not figured out how to do that.
That worked a treat!
From trying to go through Peter Judge's ETAF Sample and some guess work, it looks like you should be able to have the detail page invoke the _row service when the page is shown, and then "just" have access to the record. But I could not get this to work.
Hopefully more complete documentation and lots more samples that we can use will be coming out from PSC on all this.
From trying to go through Peter Judge's ETAF Sample and some guess work,it looks like you should be able to have the detail page invoke the _row
From trying to go through Peter Judge's ETAF Sample and some guess work,
it looks like you should be able to have the detail page invoke the _row
Before anything else happens, always make sure your casing is right.
service when the page is shown, and then "just" have access to the record.But I could not get this to work.
service when the page is shown, and then "just" have access to the record.
But I could not get this to work.
There are a couple of things at play here.
The first important thing has to do with the nature of the JSDO services. These are the services you find under the "Services" node in the MAB, and which are grouped by the REST service. In AETF you have VehicleOrderService.* and SecurityTokenService.SecurityTokenService. Each of these have a _Settings, a _JSDO and a Read. For the VehicleOrderService.ShoppingCartService we also have VehicleOrderServiceShoppingCartService_CaptureOrder and _CalculateDiscount - these 2 are the invoke operations. We will say no more of them.
_Settings contains information about where the REST services and catalog can be found. _JSDO is basically a NEW() on the jsdo.
_Read corresponds to the read operation. This performs a server call (by default, although this can be changed) and takes the famous 'filter' parameter. It returns a populated ProDataset.
There are also the _Row, _Delete, _Create and Update services that are provided per table. For example, VehicleOrderServiceShoppingCartService_eShoppingCart_Row and VehicleOrderService_ShoppingCartService_eShoppingCart_Create. The _Create, _Update and _Delete services perform a server operation. You can bind inputs to from the UI to these services. _Row is local-only (if I remember correctly) and find/fetches a record from the jsdo into the "local buffer" (kinda sorta the right term).
How do you know which record to send? This is where point #2 comes in ...
The second, very important thing, is that the JSDO add an _id field to all temp-tables. Think of this _id field as you would with the RowIdent field in an SDO or (stretching maybe) a ROWID or RECID. It's intended to be an internal (unique) identifier for the data the JSDO knows about. You don't need to know what the value is, nor how it got there: the JSDO populates it for you.
Why it's uber-important is that it is the _Row service uses one of these _id values to perform a find/lookup. You'll see that
What that does is to store 2 values in (kinda sorta) private data for the list item.
//JSDO id value for VehicleOrderServiceBrandData_eVehicle_Row services
And so on to the last part (for now). The vehicledetail page has a couple of PageShow events. Not Load, since that fires just once. The first event is to invoke the vehicleRow service. If you look at the bindings in the Data tab, you can see that the vehicleId local storage variable is bound to the Request's id parameter. This will result in the correct row being found and used to populate the UI, per the bindings on the 'Response' tab (although not in this page's case; it does other stuff first).
var cart = VehicleOrderService_ShoppingCartService_JSDO.jsdo
.findById(localStorage.getItem('cartId')); // returns JSRecord
Note in the above how we get a value from localStorage and use if to call findById. The value is then used to update the UI:
Tiggzi('detail_cart_total').text('Cart total ' + accounting.formatMoney(cart.data.Price));
Hope this clarifies matters a little,
Please make sure the documentation team also know this
Sent from my iPhone