In Part 1 and Part 2 of this series I covered how to make simple inline itemEditors as well as how to use events to make more complex itemEditors that can respond to what the user enters and help the user make fewer mistakes.
This article is about using one class to display and edit the data by employing itemRenderers as itemEditors. I tend to think of it more as an itemEditor used as an itemRenderer, but that's just me.
I have to be honest and say I am not a big fan of the renderer-as-editor; I think renderers should present data and editors should edit it. There are, however, a few occasions when I think it is a good idea to use a single class for both, but those instances are very rare in my opinion.
Examples, good and bad
Figure 1 shows an example of overusing the itemRenderer-as-editor. On the left is a nice, clean DataGrid. All of the cells are editable and when you click or tab into a cell its editor appears. In contrast, the DataGrid on the right uses itemEditors to render the cells and edit them. All you see are the editors: TextInput controls for some columns, a ComboBox for another, and a NumericStepper for the last. There is too much going on, and it is very busy to look at.
Figure 2 shows an example of using the CheckBox as both an itemRenderer and an itemEditor. I think the CheckBox works really well for this. It is a clean, simple control and you can readily see whether a value is true or false. Plus you can just click it to change it. This provides both a straightforward implementation and a good user experience.
Implementing a shopping cart
Another example of using an itemEditor as a renderer is shown in Figure 3. This List control represents a shopping cart, which contains items added to your cart while shopping online at your favorite grocery store.
As you can see, the quantity of each item in the cart is represented by a NumericStepper. This is another appropriate use of an itemRenderer as editor. All the user has to do is change the quantity and the cart is updated. A delete button would also be a good idea here, too.
The complex editor/renderer class shown in Figure 3 works as follows:
<?xml version="1.0" encoding="utf-8"?><mx:HBox xmlns:mx="http://www.adobe.com/2006/mxml" verticalAlign="middle" paddingRight="4" paddingLeft="4" > <mx:Script> <![CDATA[ public function get quantity() : Number { return itemQuantity.value; } ]]> </mx:Script> <mx:CurrencyFormatter id="cfmt" precision="2" /> <mx:Label text="{data.name}" fontWeight="bold" fontSize="12"/> <mx:Spacer width="100%"/> <mx:NumericStepper id="itemQuantity" value="{data.quantity}" minimum="0" maximum="100"/> <mx:Label text="{cfmt.format(data.price*itemQuantity.value)}" width="66"/></mx:HBox>As with every itemEditor, this one has a property used as the editorDataField. In this case it is the quantity property getter function. The function retrieves the value setting of the NumericStepper (specifically, the one with the id itemQuantity).
As an itemRenderer, this component must also display the current quantity (as well as the product name, price, and subtotal). These values are displayed through data binding. The subtotal is actually an ActionScript expression, multiplying the price by the value of the NumericStepper. As the NumericStepper changes so does the subtotal.
Now you are probably wondering how to update the grand total below the shopping cart as the NumericSteppers are changed. Simply changing the subtotal and the quantity field of the itemRenderer/editor will not update the grand total. Remember that the editor does not commit the new value into the data provider until after the edit completes. In other words, if you increase the value of the NumericStepper for the Snow Peas row, the grand total will not update until focus leaves the Snow Peas row. This is so you can validate the information as shown in Part 2 of this series.
For a shopping cart like this, you want the grand total to update as the user changes the NumericSteppers—so you have to force the situation a little.
The first thing you do is have the itemRenderer class implement the IDropInListItemRenderer interface. This gives you access to the listData, which contains a reference to the list itself and, through that, a reference to the dataProvider.
Note: The code demonstrating this is available in the sample files for this article. Look for the ShoppingCartRendererExtra.mxml file.
Once you have the listData you can have the change event on the NumericStepper force an update on the dataProvider:
private function forceUpdate() : void{ // Access the collection - listData.owner is the List and from there you have its dataProvider. var ac:ArrayCollection = (listData.owner as List).dataProvider as ArrayCollection; // update the quantity field from the numeric stepper. This is what the List will automatically // do when editing completes, but since you want to see the grand total change as the NumericStepper // changes, you have to force things a bit. data.quantity = itemQuantity.value; // finally, tell the collection the data changed. this will cause the collection to // dispatch its own change event which is then picked up by the main application. ac.itemUpdated(data);}When the NumericStepper's change event triggers this event handler, the ArrayCollection has the item updated immediately, rather than waiting for the List to complete editing the cell. If the main application is listening for a COLLECTION_CHANGE event on the collection, the grand total can be calculated:
<mx:ArrayCollection id="shoppingCartDB" source="{shoppingCartArray}" collectionChange="updateCartTotal()" />...private function updateCartTotal() : void{ if( cartTotal ) { var total:Number = 0; for(var i:int=0; i < shoppingCartDB.length; i++) { var record:Object = shoppingCartDB.getItemAt(i); total += record.price * record.quantity; } cartTotal.text = cfmt.format(total); }} Where to go from here
Take care when turning an itemRenderer into an itemEditor. The user should have a straightforward interface with a single purpose when editing a cell or record. I personally prefer to separate the functions, but there are times when using an itemRenderer as an itemEditor can make sense, even if you have to go the extra mile as with the shopping cart grand total example.
There are plenty of examples of item renderers and editors on the Internet these days. If you have an idea you want to try out, see if others have tried something similar. The Adobe Flex forums are also another good resource where developers can discuss their challenges and provide solutions.
