Master detail and validation errors

[pfouche]

I have a use case similar to the master detail example in :
http://www.smartclient.com/smartgwtee/showcase/#master_detail_batch

I'm wondering how to report and show validation errors on details records (order items in the example).

What should be the format of the validation errors coming from the server? Something like

  errors:[
            {
                "items[0]/quantity":[
                    "must be positive"
                ], 
                "items[1]/unitPrice":[
                    "must be positive"
                ]
            }
        ],

?

Do I have to iterate over the errors and add them them to the orderItemsList grid using ListGrid.setRowErrors()? Or is there a smarter way of doing it?

Note that I'm using a custom data source on the server side as I'm using a NoSQL database.

Thanks for your help.
--Pierre

[Isomorphic]

Take a look at the QuickStart Guide, there's an example of reporting errors in the sections on DMI. You don't need to worry about format, you just call a server-side API.

[pfouche]

Thanks for the quick reply, Isomorphic.

I did read the QuickStart guide, but there is nothing in the DMI section about handling validation errors with master-detail relationships.

Considering again the master-detail showcase (http://www.smartclient.com/smartgwtee/showcase/#master_detail_batch), how can I add a validation error for, say, the unitPrice of the second ordered item? Should I call dsResponse.addError("items[1]/unitPrice", "must be positive"), using a pseudo xpath syntax for the field?

Assuming this is the right field syntax, how can I get this error displayed in the orderItemsList grid?

Thanks,
Pierre

[pfouche]

Isomorphic, anyone, any idea?

Thanks,
Pierre

[Isomorphic]

Sorry, we didn't realize you were trying to send nested errors.

The problem in this case is that the form initiates the entire save. The grid is not involved, so it won't automatically get any errors.

The preferred way to do a master-detail save is in this style - a queue of *separate* operations for the master and detail records so that each initiating component gets a separate response.

This also makes the two DataSources orthogonal so that you can do separate fetches of each type of record, which opens up many more features (eg, paging through an order with a very large set of orderItems).

[pfouche]

Ok. I looked at the "transactions queued" example and I think it makes sense in some cases.

However, in our case, it makes things more complex to manage on the server side, as we have to save the master and its details in a single "document" (we're using a no sql database). Having queued, separate operations would force us to reconstruct the whole master-details assembly in the last operation. That sounds unnatural and brittle.

The "embedded" scenario sounds a better fit for us, and it would be nice to have some kind of support for nested errors. Is it something you could natively support in a future release ?

Many thanks,
Pierre

[Isomorphic]

Fundamentally you've got operations on two different entities here, with different validation rules and potentially security rules for each. We do think it makes sense to encapsulate this as two separate operations with separate DSResponses, etc. Again, this allows fetching orderItems across different orders (for reporting functions, for example), paging across large numbers of orderItems, etc. The "unnatural and brittle" aspect actually comes from your system that requires orders and orderItems to be delivered as one nested document instead of properly separating the APIs for each.

However, such systems come up a lot (eg poor WSDL design) and we may add this as a feature in a future release - it would be oriented around the ValuesManager and it's ability to manage a nested data structure being edited by multiple components. If you need this on a particular timeline, the Feature Sponsorship program allows you to do this.

[pfouche]

Ok. Let's assume we go the "queued, separate operations" way.

In our case, we have another problem to solve: We have to maintain the ordering of orderItems. To do that, I suppose we have to manage a "rank" field in the orderItem.

Let's assume we have an order with 5 items and we want to add a new item between items 3 and 4. Inserting the new item would result in a "add" operation with a rank 4 for the new item, but we would also have to update the rank of the subsequent items (4 and 5, becoming 5 and 6).

How can we tell the client that this "add" operation triggered two other "update" operations and that the other orderItems need to be refreshed?

Note that in the "embedded" way, we wouldn't have to manage this "rank" field, as the whole list of items would be persisted in a single operation.

Thanks,
Pierre

[Isomorphic]

Sorry, it's unclear why you want a "rank" at all. Having a primaryKey field makes the edits unambiguous. You do need to maintain a rank if you want to allow the user to reorder items and persist the order of the items, but if you want such a feature you'd need a "rank" field regardless of the approach.

[pfouche]

Yes, we do want to allow the user to reorder items and persist the ordering.

But no, I don't think we would need a "rank" in the "embedded" approach: SmartGWT would send an array of orderedItems as part of the master "order". As our backend system can natively persist the array as part of the enclosing "order" document, the ordering would be naturally preserved.

Coming back to the "separate operations" approach, as the subsequent orderedItems rank would be updated when a new orderedItem is inserted, I suppose we need to call DSResponse.setInvalidateCache(true) to tell the client that the remaining orderedItems are no longer valid. Is it correct?

Thanks,
Pierre

[Isomorphic]

? If your backend can persist an array of items, you'll be getting an array of in-order requests from the client from which you can form such an array. So again no need for a rank attribute.