This sample would contain 3 models.
Order Summary - OrderID, OrderNumber, Customer Number, CustomerName, Date, StatusDESC, Amount, etc. This would be a summary record used by a search/list screen most likely served up by a database view.
Order Header - OrderID, OrderNumber, CustomerID, Date, StatusID, Amount, etc - A hasMany association to a list of Order Line Items.
Order Line Item - OrderID, LineNumber, SKU, ItemDesc, Quantity, Price, SubTotal, etc.
The first search screen would be a grid connected to a store of OrderSummaries. There would be a box for typing in an order number,customer number, or date range to search.
When the user drills down into an existing record, a new screen or tab is opened, where the order summary (or id) is passed into the detail view (not for binding to the screen). The detail view would load the full order header model and associated hasMany orderlineitems using the passed in id. The screen would have the order header info at the top and a grid at the bottom bound to the line items. The customerID and statusID will be connected to comboboxes that map to names.
There will also be an add button on the search screen. Clicking it will open the same screen as above, but in add mode. I'd like to see a call that loads the default order header values from the server. I will leave it up to you to decide whether adding lineitems will be via another add button that opens a modal dialog, or maybe even an embedded line item detail fieldset beneath/above the grid for adding/editting line item details, or maybe even inline grid editting. The combobox for sku in all three cases, including the grid, would be a remote query one. Ideally , you could provide a sample of all three with a dropdown on the search screen of which mode to demo. Most likely different screens, depending on the complexity of the master/detail objects will use one of the three methods above. At least this way, you can leverage the existing three models to show three ways of data entry.
When adding/editting line items, there must be a server side validation call that would look up the price for that customer for the given sku and quantity and also verify the sku is in stock. This part ideally would show how to have the server display it's validation errors in the same method as your built in client validation. For example, if somebody orders 10, and only 5 are in stock, it will need to show an error on the quantity.
There should be an ability to delete line items.
Notes
1) No HARDCODED data. I'd like to see proxy declarations where needed. Worst case, you provide a real working sample on your website with proxies so we can fiddler the data going back and forth and for local, it uses whatever.
2) Please do not shortcut the sample by passing the search screen's summary record down into the detail view to just bind to that. I am not going to load all the order columns for the search screen. On the order detail screen it's ok to pass the line item objects around. You'll be demoing both concepts.
3) When creating/saving the order, I'm assuming order.save() sends all associated data in one request.
4) After an order is created,and the server responds with an updated model, I want to see that the id assigned to the order (and any other updated fields) is then displayed on the screen.
5) Bonus, the search screen is told to fetch that specific newly created order id summary, and the record is inserted at the top of the grid.
Sencha, please, can you work on this sample? I am dead in the water. This basic pattern will help tremendously with so many more screens.
I would post this in the premium section, but I am thinking there are lots of people trying to do the same thing that would like a clear example from you on the recommended way to do all this.
Order Summary - OrderID, OrderNumber, Customer Number, CustomerName, Date, StatusDESC, Amount, etc. This would be a summary record used by a search/list screen most likely served up by a database view.
Order Header - OrderID, OrderNumber, CustomerID, Date, StatusID, Amount, etc - A hasMany association to a list of Order Line Items.
Order Line Item - OrderID, LineNumber, SKU, ItemDesc, Quantity, Price, SubTotal, etc.
The first search screen would be a grid connected to a store of OrderSummaries. There would be a box for typing in an order number,customer number, or date range to search.
When the user drills down into an existing record, a new screen or tab is opened, where the order summary (or id) is passed into the detail view (not for binding to the screen). The detail view would load the full order header model and associated hasMany orderlineitems using the passed in id. The screen would have the order header info at the top and a grid at the bottom bound to the line items. The customerID and statusID will be connected to comboboxes that map to names.
There will also be an add button on the search screen. Clicking it will open the same screen as above, but in add mode. I'd like to see a call that loads the default order header values from the server. I will leave it up to you to decide whether adding lineitems will be via another add button that opens a modal dialog, or maybe even an embedded line item detail fieldset beneath/above the grid for adding/editting line item details, or maybe even inline grid editting. The combobox for sku in all three cases, including the grid, would be a remote query one. Ideally , you could provide a sample of all three with a dropdown on the search screen of which mode to demo. Most likely different screens, depending on the complexity of the master/detail objects will use one of the three methods above. At least this way, you can leverage the existing three models to show three ways of data entry.
When adding/editting line items, there must be a server side validation call that would look up the price for that customer for the given sku and quantity and also verify the sku is in stock. This part ideally would show how to have the server display it's validation errors in the same method as your built in client validation. For example, if somebody orders 10, and only 5 are in stock, it will need to show an error on the quantity.
There should be an ability to delete line items.
Notes
1) No HARDCODED data. I'd like to see proxy declarations where needed. Worst case, you provide a real working sample on your website with proxies so we can fiddler the data going back and forth and for local, it uses whatever.
2) Please do not shortcut the sample by passing the search screen's summary record down into the detail view to just bind to that. I am not going to load all the order columns for the search screen. On the order detail screen it's ok to pass the line item objects around. You'll be demoing both concepts.
3) When creating/saving the order, I'm assuming order.save() sends all associated data in one request.
4) After an order is created,and the server responds with an updated model, I want to see that the id assigned to the order (and any other updated fields) is then displayed on the screen.
5) Bonus, the search screen is told to fetch that specific newly created order id summary, and the record is inserted at the top of the grid.
Sencha, please, can you work on this sample? I am dead in the water. This basic pattern will help tremendously with so many more screens.
I would post this in the premium section, but I am thinking there are lots of people trying to do the same thing that would like a clear example from you on the recommended way to do all this.
Request for advanced MVVM Master/Detail sample.
Aucun commentaire:
Enregistrer un commentaire