Simple master detail example

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.

Thanks Marko,

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.

Regards / Med Venlig Hilsen 

Thomas Hansen

Director

+1

Thomas,

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.

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

In the styles page, in the readBrandData service response, in the mobilelistitem1_17 javascript, you'll see the following code:

$(element).attr('data-vehicle-id', value._id);

$(element).attr('data-item-id', value.ItemId);

What that does is to store 2 values in (kinda sorta) private data for the list item.

When an item is selected, the Click event has 2 handlers. One Javascript and on changes pages to the 'vehicledetail' page. The JavaScript takes that _id value we stored away (above) and sets a localstorage value. So ...

//JSDO id value for VehicleOrderServiceBrandData_eVehicle_Row services

localStorage.setItem('vehicleId', $(this).attr('data-vehicle-id'));

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).

You can of course also do this manually, in Javascript. From the AETF sample's vehicleorder.js, at around line 436:

var cart = VehicleOrderService_ShoppingCartService_JSDO.jsdo

.eShoppingCart

.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));

Tiggzi('detail_cart_total').refresh();

Hope this clarifies matters a little,

-- peter

Thanks Peter,

Please make sure the documentation team also know this

Sent from my iPhone