[ohmi]

more questions

Is it necessary to convert all the way to ListGridRecords?

Is there still a need for a separate Address DataSource in this example?

Farrukh, could you perhaps post a bit more of this code, showing how the DataSource are defined and what happens when the master record (the Person in your case) is updated?

[rolgon]

Problem with saving edits to nested grid

Update: I found the solution myself: ListGrid.getEditedRecord retrieves the edited value. Its a pitty there is no getEditedRecords method though..

----------------------------------------------------------------------------------------

I have a similar requirement to the one that farrukh_najmi describes.

I am able to populate my adressesGrid list using the approach described by farrukh_najmi. However, I would also like to be able to update the adressesGrid and save the changes to the adressesGrid at the same time as the person is saved.

So, I have set the adressesGrid to be editable. When the user edits an existing adress or adds a new one, these are successfully displayed in the UI.

I then need to move the data from the updated adressesGrid back to the original person record. However, when I call adressesGrid.getRecords() I get the original data without the changes done by the user.

How can I access the modified data in the adressesGrid list?

Thanks
Rolf

[Isomorphic]

@rolgon Take a look at this sample. There's no need for getEditedRecord() if you set saveLocally:true (presumably you have autoSaveEdits:false instead).

[aze_kool]

Hi Isomorphic,
based on your description i have used a similar scenario. currently i am having a problem which i have described in the following thread :

http://forums.smartclient.com/showthread.php?t=21378

could you please help me with this.

Best Regards

Hi guys,

Taking a step back to provide more context, the primary way of dealing with "nested" records in SmartClient is to treat them as two related DataSources that are linked by foreignKey.

For example, take "orders" and "items", where logically orders contain items, and there are DataSources "orders" and "items" that are related by foreignKey. You have an interface consisting of a grid bound to the "order" DataSource showing orders and a form next to that grid, also bound to the "order" DataSource, for showing all the fields of the order, and finally a second grid bound to the "items" DataSource.

In this scenario, the data loaded in the "orders" grid does not contain the data for the "items" for that order - it only has the fields of the order as such (like shipDate). To populate the "items" grid you just call fetchRelatedData() (*see below) on that grid, passing the selected order. You need to make the "items" DataSource capable of receiving an order id as criteria and returning the items from that.

Likewise if the order is edited and items are also edited, these will be independent DSRequests that your server code needs to deal with. There will be one DSRequest per added/modified item.

This is the right approach if the number of items is potentially very large and data paging may be required. It's also potentially the more efficient approach if users don't often click through to view the items from most of the loaded orders, since it would then be a waste to load all the items data up front.

The alternative is to load the items with each order, in advance. In this case the list of items ends up as an attribute/property of each "order" record. In place of fetchRelatedData() to populate the "items" grid, you take the Array of items from the "order" record and call setData() on the "items" grid - there's no server fetch and the "items" DataSource does not need to be capable of fetching. When saving, you call dataSource.updateData() passing the "order" record (which contains the items). The "items" DataSource does not need to be separately capable of "add" or "update".

In this case there is no foreignKey declaration and the field's type is "items" (the name of the related DataSource) *see below

Then, actually deliver the items to the browser as part of the order record, in both the SC server and the XML version it's sufficient to just include the data. In the SC server case if your DataSource field matches the name of the getter for the "items" on your POJO (for getItems() field name would be "items" as per Java Bean convention), you're done. For the XML case you want to set multiple:true on the field definition, then deliver the data like this:

<order>
    <shipDate>1976-09-12</shipDate>
    <items>
         <item>
             <name>foo</name>
             ...
         </item>
         <item>
             <name>bar</name>
             ...
         </item>
     </items>
     ...
</order>

For saving, both the RestDataSource and SC Server DataSource are going to send the data along automatically (use dataProtocol:"postMessage" with RestDataSource). For RestDataSource you'll need to parse the XML, validate it and make it the right type and call setters on your beans.

For the SC server it's sufficient to just declare an Order bean as one of the parameters of a method invoked via DMI, and SmartClient will just fill in the bean after running validation.

* API currently missing in SmartGWT, look for it in an upcoming nightly.