Page 2 of 4   « previous page   next page »

Last, to select a specific value in a radio button group, use the selectedData property:

myRadioButton.selectedData = listingGrid.selectedItem.columnName;

Putting everything together, the complete listingGridChanged() function looks like the following:

function listingGridChanged():Void {
    // select the matching state
    selectOption(edit_state, listingGrid.selectedItem.state);

// select the matching property type
    selectOption(edit_type, listingGrid.selectedItem.type);

    //select the matching choice in the radio button
    //for status
    edit_status.selectedData = listingGrid.selectedItem.status;

    //after selecting a radio button, it acquires focus, so bring focus back to grid
    listingGrid.setFocus();
}

Now the edit panel is correctly populated with the data in the selected row and the user can edit it and submit it to the server.

Note that if you use listingGrid.selectedItem.columnName directly, and there is no item selected in the datagrid, your controls may show undefined as their value. To avoid that, use the if-else shorthand statement to check whether the user has selected an item in the datagrid. If the user has selected an item, show the value; otherwise, show an empty control. For example, the city text input looks like the following:

<cfinput type="text" name="edit_city" bind="{
(listingGrid.selectedItem!=undefined)?
listingGrid.selectedItem.city:''}" label="city" />

Adding, Updating, and Removing Records
Before continuing with the user interface, you must prepare the components that handle the insert, update, and delete queries. Just as you did for the search functionality, you must write two components - one that interacts with the database and one that acts as a service waiting for Flash Remoting calls.

First, create the first component by making a file called ListingDAO.cfc and place it in the \realestate\components\ directory.

Because the ListingDAO component will handle all the queries (insert, update, and delete), it contains four functions: create, update, delete, and fetch - a function to get a specific record from the database. Create and update functions will receive a set of arguments representing each listing attribute, such as address, number of bedrooms, or square footage. Delete and fetch require only the record's primary key.

In ListingDAO.cfc, add the code in Listing 1, inserting all the arguments, completing the query, and implementing the other four functions:

The Fetch function takes an mls_id and returns a structure with the corresponding property listing matching the mls_id. This structure will later be used to populate the created or updated records in the datagrid. Refer to the sample files you downloaded in the Requirements section to see the complete code for all the functions in this component.

Creating the Flash Remoting Service
Flash Remoting connects the user interface with the component you just wrote. Now you need to expose the component's function as Flash Remoting services so that the user can actually change data in the database. You do not need to write the service component from scratch; you can simply add the necessary functions to the ListingService.cfc component file described in Part 1 of this tutorial.

You must add functions to handle an insert request (<cffunction name="create">), an update request (<cffunction name="update">), and a delete request (<cffunction name="remove"). As with the search function, you can directly pass the same arguments to the ListingDAO component. When using functions as Flash Remoting services, set their access attribute as "remote" (access="remote").

Add the code in Listing 2 to the ListingService.cfc from Part 1 or use the ListingService.cfc file included in the sample files in the Requirements section in this tutorial.

These newly added functions return a structure with a "status" field, indicating whether the operation was successfully performed, and an "item" field to return the updated or created item. You may wonder why it is necessary to send the item back to the client interface. The reason is that any Flash Remoting call is asynchronous, which means that when your application returns the result of a record insert or update, the user may have changed some inputs or the datagrid selected item - you cannot rely on the data in the form fields at that time.

Calling the Service and Handling the Result
At the bottom of the edit form in the index.cfm file, there is a button to submit the form:

<cfinput
type="button"
name="editBtn"
onclick="submitEdit()"
value="{(listingGrid.selectedItem == undefined)?'Submit':'Apply Changes'}" />

You may have noticed that it's not an input-type submit. Just as with the search panel, the submit button is implemented with a simple button that calls a function when it's clicked (onclick="submitEdit()"). In addition, its label is dynamic and changes depending on whether a user has selected an item in the datagrid, which indicates the user is editing a record; or nothing is selected, indicating that the user is entering a new record.

To change this label, use the value attribute and a binding with a shorthand if-else statement that tests for listingGrid.selectedItem == undefined, meaning no item was selected. In that case, the value becomes "Submit' for new records; otherwise the value becomes "Apply Changes" for a record that's being updated.

You'll also declare and implement the submitEdit() function in a <cfformitem type="script"> block in index.cfm. Following the same method used to submit the search form, gather the data contained in each input, radio button, select, text area, and check box to send to the service method. Unlike the search panel, you must validate this form before submitting it.

There are several required fields and fields that accept only numbers, zip codes, and other validation types. When a user submits a form using a <cfinput type="submit"> tag, Flash Forms run the validation automatically and don't submit the form until it validates entirely. Because you don't use a submit button, but a regular button, the form does not automatically run this validation. To ensure that you validate the form before sending the data to the Flash Remoting service, use the following code to test it:

if( mx.validators.Validator.isStructureValid(this, 'RealEstateAdmin') ){
    //make the call
}

Add this test right before sending the data to the Flash Remoting service in the submitEdit() function of the index.cfm file. If mx.validators.Validator.isStructureValid(this, 'RealEstateAdmin') returns true, it means the form is valid and you can proceed with the call.

Recall that RealEstateAdmin is the name of the form. Change it according to your own form name. Calling this function indicates whether there are validation issues; it also activates the red error tips and red border on the fields so that the application informs the user about what he or she needs to complete or modify.

Last, because you use the same button to submit a new record and an updated record, the function must know what service method to call (update or create). For simplicity's sake, check for the grid selected item - the same test you did to change the submit button's label value. A more complex approach would be to set a global variable that indicates whether the user is in "edit" or "add' mode. The sample files use a global variable called isEditMode, which is set when the user changes the selection in the datagrid.

You make the Flash Remoting service call in the submitEdit() function using the same service connection object you created in Part 1 that was stored in a global object and called:

RealEstateAdmin.myGlobalObjects.listingService

The function you create to handle the submit gathers the form data from each field as it was described in Part 1 when gathering the Search panel data (see Listing 3).

After making the call, the server returns a successful response. But your form is not yet ready to handle that response.

Page 2 of 4   « previous page   next page »