Extjs practice (8)-Crud + paging + complex query + sorting

Now we start to parse crud + paging + complex query + sorting. Their integrityCodeOn the front init-house.js.

 

Our general idea is that list, query, add, and modify all use extjs to access the background, while ID-based single record search and batch deletion are handed over to DWR, next we will analyze them one by one according to the functional division.

The first is the list function with pagination. The core implementation code is as follows:

 

DS = new Ext. Data. Store ({

// Proxy: New Ext. Data. memoryproxy (jsondata ),

Proxy: New Ext. Data. httpproxy ({

URL: '../house. Do'

}),

Reader: New Ext. Data. jsonreader ({

Totalproperty: 'totalproperties ',

Root: 'root'

},[{

Name: 'hid'

},{

Name: 'title'

},{

Name: 'linkman'

},{

Name: 'linktel'

},{

Name: 'hireprice'

},{

Name: 'booktimeinfo'

},{

Name: 'ommting'

},{

Name: 'areastreet'

}])

});

DS. Load ({

Params :{

Start: 0,

Limit: Limit

}

});

Ext. Data. Store is a very important class in extjs. It is usually translated into a data source because it determines where to obtain data and how to parse the data. According to the code above, we know that this data source is accessed by a remote server .. /house. do resources, and a JSON object will be obtained. The JSON object returned by the server contains two names: totalproperty and root. The former contains the total number of records in the code, the latter is the number of records on the current page. When we access the data source for the first time, of course, we load a maximum of limit (Defined variables) data records starting from 0. In the future, we can obtain paging data based on the paging toolbar provided by extjs. The START and limit parameters are transmitted to the server through the HTTP protocol.ProgramIn this way, we can use these two parameters in the background code to complete the list function with pagination. Note that the server must return data in JSON format, otherwise, the store cannot be parsed!

Then there is a powerful query function. The core code is as follows:

Function query (){

// The key here is to reload the data source and submit the search form value

DS. Load ({

Params :{

Start: 0,

Limit: PTB. getpagesize (),

'Cond. title': Ext. Get ('title'). Dom. value,

'Cond. areaid ': Ext. Get ('area'). Dom. value,

'Cond. streetid': Ext. Get ('street'). Dom. value,

'Cond. room': Ext. Get ('room'). Dom. value,

'Cond. ting': Ext. Get ('ting'). Dom. value,

'Cond. booktime': Ext. Get ('booktime'). Dom. value,

'Cond. pricestart': Ext. Get ('pricestart'). Dom. value,

'Cond. priceend': Ext. Get ('priceend'). Dom. value,

'Cond. sortcond': dwrutil. getvalue ("sortcond ")

// Obtain the value in radio in another way

// Obtain the text field value of the search form and send it to the server.

}

})

 

}

We made a multi-field condition combination query form. clicking the OK button will trigger the query () function. In the query () function, we reload the data source, note that the parameter Ext. get ('title '). dom. value and dwrutil. getvalue ("sortcond") is a method to obtain the value of a form field. The preceding parameter name is used. There may be two strange points. First, what is PTB. getpagesize () and why is it written like this? Why is the preceding parameter name cond. Title like this? Can I change it to another name? First, if you do not need to dynamically change the number of records displayed on each page, you can write a constant. However, the default pagination toolbar is expanded in our application to allow it to freely change the number of records displayed on each page. In this way, we need to make the query consistent with the settings on the page toolbar. PTB indicates the object in the paging column. The second question requires your brains. We all know that struts can automatically populate the form data on the page with the actionform attribute value, but now we all use the entity class as the actionform attribute. So, in order for struts to correctly set the parameters of the submitted form to the actionform object, we have to pay a little price that the parameter name must be prefixed with the DTO attribute name! Here, we have achieved three major difficulties in data retrieval: Paging, sorting (both on the client and server) and filtering!

 

Next, add the function. The core code is as follows:

Handler: function (){

If (Form. Form. isvalid () {// use the loading progress bar after verifying the validity

// Submit the operation to the server

Form. Form. doaction ('submit ',{

URL: '../househandler. do? Action = addhouse ', // file path

Method: 'post', // submit the post or get Method

Params :'',

// Callback function for successful submission

Failure: function (retform, retaction ){

If (retaction. Result

& Retaction. Result = '1 '){

Ext. MessageBox. Alert ('hprompt ',' data is saved successfully! ');

Win. Hide ();

PTB. cursor = PTB. Store. gettotalcount () + 1-ptb.pagesize;

DS. Load ({

Params: {

Start: PTB. cursor,

limit: PTB. pagesize

}

});

 

} Else if (retaction. Result

& Retaction. Result = 'error '){

Ext. MessageBox. Alert ('hprompt ',' failed to save the data! ');

} Else {

Ext. msg. Alert ('error', 'server error. Please try again later! ');

}

},

Waitmsg: 'Save the data ...'

});

}

}

If you still remember the last login application, you should find that the process of adding form submission is similar to that of login, but there are several minor differences. First, we define the failure in terms of the nominal value. By default, if the returned value is not a JSON object, it is a failure. Therefore, the server does not need to return JSON data for processing the action, but only needs to return the number 1. As long as the client receives the return value of 1, the server adds the operation successfully. It will make a success prompt and reload the data on the last page (because the newly added data is always displayed on the last page by default, therefore, it is very user-friendly to directly display the records on the last page after adding data !)

 

The Edit function is followed. The core code is almost identical to the Add function, but the read-only form attribute with multiple IDS is edited. It needs to tell the server that the record is to be modified! Then, after editing, the data is refreshed, but the record editing page remains (as user-friendly as adding )!

 

Then, you can find a single record by ID. This is what you need to do before opening the editing window, because editing is to modify the original record, therefore, we need to use DWR to obtain the house information corresponding to an ID on the server, and then display it in the editing form.

 

The last step is batch Delete. We use the check box to get the id value to be deleted, and then use DWR to upload them as dynamic arrays to the server for batch Delete. After the deletion is complete, it will also stay on the most appropriate page. In this way, we have completed basic CRUD, paging, complex query, and other functions. Below is: