Design and implementation of e-commerce systems (10): Integration of the DWZ framework and third-party paging components; e-commerce system dwz

Design and implementation of e-commerce systems (10): Integration of the DWZ framework and third-party paging components; e-commerce system dwz
In the evening, we just used the DWZ framework in the backend management system.
First, directly use the Demo on the official website, dwz-jui, the original static project unrelated to the programming language.

Soon, the left-side menu is set up. After the menu is opened, the Tab page appears and the content of the target page is displayed.

Then, focus on the page part of the table.

The paging component provided by DWZ is too troublesome. On the one hand, the paging component is divided into four parts for display, mainly including:
PagerForm, query Condition
PagerHeader: the header of the paging table
PagerContent: the body of the paging table
PanleBar: the number of tabs.

On the other hand, the backend variables must be displayed in html and JS pages.
The list set and paging parameters of the table body must be obtained from the backend, such as the Java context variable. See the following example:

<Form id = "pagerForm" method = "post" action = "demo_page1.html"> <input type = "hidden" name = "status" value = "$ {param. status} "> <input type =" hidden "name =" keywords "value =" $ {param. keywords} "/> <input type =" hidden "name =" pageNum "value =" 1 "/> <input type =" hidden "name =" numPerPage "value =" $ {model. numPerPage} "/> <input type =" hidden "name =" orderField "value =" $ {param. orderField} "/> </form> <div class =" pageHeader "> <form onsubmit =" return navTabSearch (this ); "action =" demo_page1.html "method =" post "> <div class =" searchBar "> <table class =" searchContent "> <tr> <td> my customers: <input type = "text" name = "keyword"/> </td> <select class = "combox" name = "province"> <option value = ""> all provinces and cities </option> </select> </td> <td> file creation date: <input type = "text" class = "date" readonly = "true"/> </td> </tr> </table> <div class = "subBar"> <ul> <li> <div class = "buttonActive"> <div class = "buttonContent"> <button type = "submit"> Search </button> </div> </ div> </li> </ul> </div> </form> </div> <div class = "pageContent"> <div class = "panelBar "> <ul class =" toolBar "> <li> <a class =" add "href =" demo_page4.html "target =" navTab "> <span> add </span> </a> </li> </ul> </div> <table class = "table" width = "100%" layoutH = "138"> <thead> <tr> <th width = "120"> customer name </th> </tr> </thead> <tbody> <tr target = "sid_user" rel = "1"> <td> tianjin rural credit cooperative </td> </tr> </tbody> </table> <div class = "panelBar"> <div class = "pages"> <span> display </ span> <select class = "combox" name = "numPerPage" onchange = "navTabPageBreak ({numPerPage: this. value}) "> <option value =" 20 "> 20 </option> </select> <span>, total of $ {totalCount} items </span> </div> <div class = "pagination" targetType = "navTab" totalCount = "200" numPerPage = "20" pageNumShown = "10 "currentPage =" 1 "> </div>

 
Therefore, I do not want to use this built-in page.
In the past, a colleague wrote the paging component in seconds. I modified the component and wanted to maintain a version by myself. Therefore, the backend uses its own paging component fugrid. js.
However, a problem occurs. Either, the grid component reports an error or the initUI function of dwz's dwz. ui. js reports an error.
Analyze the problem:
On the New Page, access the page where the grid component is located. The page is displayed normally, indicating that the code is correct.
The initUI function does not report any error when using the built-in table.

Continue analysis:
It is found that the initUI method will call some methods, $ ("div. panel", $ p). jPanel (); and then prompts XX that there is no jPanel method, which eventually causes the grid component to become stuck. I don't want to modify the code of the grid component. The code of the dwz component has not been understood yet, and I don't want to modify it. It will be troublesome to modify the code for future upgrades.
I tried one way. Since the grid component remains stuck due to an error reported by dwz, if this error is captured?

  try{initUI();}catch(e){console.warn(e);} 

Add the try-catch Block or report an error. Is it a cache?
<Script src = "static/framework/dwzjs/dwz. ui. js? A = 1 "type =" text/javascript "> </script>
Add a parameter a to prevent caching and report errors.

Alternative method:

function initUI(_box){var $p = $(_box || document);try {   $("div.panel", $p).jPanel();       }catch(e){console.warn(e);} }

In the initUI method, it is okay to catch this exception.

You do not need to modify the business logic of dwz or the code of the grid component.
If dwz is upgraded, you only need to add the code to capture exceptions after the upgrade. You do not need to worry about the logic of the dwz component.