Question JQuery Programing Help Needed

Hi,
Those who have done some work with JQuery please help me.
I am trying to populate the records from Sport200o DB, employee records. I partially suceed in that. I would like to improvise this. Is it the right way to fetch the data ? Here in case of massive data in the table, entire data coming to the grid. Instead of this how can bring the record in batches from the database to Grid when user flip to the NEXT & PREV pages (Only 50. 60 , , 70 ... records will fetch depends on the drop down selection in the grid page)? Give some clues how to make this small code to very generic. Means passing the table name and field names as arguments instead hard coding.

TIA
-Philip-

HTML:
<html>
<head>
    <meta charset="UTF-8">
    <title>Build CRUD DataGrid with jQuery EasyUI - jQuery EasyUI Demo</title>
    <link rel="stylesheet" type="text/css" href="http://www.jeasyui.com/easyui/themes/default/easyui.css">
    <link rel="stylesheet" type="text/css" href="http://www.jeasyui.com/easyui/themes/icon.css">
    <link rel="stylesheet" type="text/css" href="http://www.jeasyui.com/easyui/demo/demo.css">
    <script type="text/javascript" src="http://code.jquery.com/jquery-1.6.min.js"></script>
    <script type="text/javascript" src="http://www.jeasyui.com/easyui/jquery.easyui.min.js"></script>
    <script type="text/javascript" src="http://www.jeasyui.com/easyui/jquery.edatagrid.js"></script>
</head>
<body>
    <h2>CRUD DataGrid</h2>
    <p>Double click the row to begin editing.</p>
   
    <table id="dg" title="My Users" style="width:700px;height:250px"
            toolbar="#toolbar" pagination="true" idField="id"
            rownumbers="true" fitColumns="true" singleSelect="true">
        <thead>
            <tr>
                <th field="firstname" width="50" editor="{type:'validatebox',options:{required:true}}">First Name</th>
                <th field="lastname" width="50" editor="{type:'validatebox',options:{required:true}}">Last Name</th>
                <th field="phone" width="50" editor="text">Phone</th>
                <th field="email" width="50" editor="{type:'validatebox',options:{validType:'email'}}">Email</th>
            </tr>
        </thead>
    </table>
    <div id="toolbar">
        <a href="javascript:void(0)" class="easyui-linkbutton" iconCls="icon-add" plain="true" onclick="javascript:$('#dg').edatagrid('addRow')">Add</a>
        <a href="javascript:void(0)" class="easyui-linkbutton" iconCls="icon-remove" plain="true" onclick="javascript:$('#dg').edatagrid('destroyRow')">Delete</a>
        <a href="javascript:void(0)" class="easyui-linkbutton" iconCls="icon-save" plain="true" onclick="javascript:$('#dg').edatagrid('saveRow')">Save</a>
        <a href="javascript:void(0)" class="easyui-linkbutton" iconCls="icon-undo" plain="true" onclick="javascript:$('#dg').edatagrid('cancelRow')">Cancel</a>
    </div>
    <script type="text/javascript">
        $(function(){
            $('#dg').edatagrid({
                url: 'get_users.p',
                saveUrl: 'save_user.p',
                updateUrl: 'update_user.p',
                destroyUrl: 'destroy_user.p'
            });
        });
    </script>
   
</body>
</html>
 

GregTomkins

Active Member
Unfortunately, I have probably spent 30% of my professional energy in the past few years dealing with this scenario in different forms. For the past couple of years I have been using jQuery + Progress almost exclusively ... however, we use it in quite a different way than what you are doing here, so, it's hard for me to make meaningful comments. I'll just throw out a few that come to mind.

1) Basically, all our Progress API's take a '# of records' input and a 'next record key' input-output. Typically if you (a jQuery client) asks for a list of customers, we'll return 100 records, let's say from Adams to Brown, and indicate that the next available customer is, say, Charles. If the jQuery client wants the next 100, he passes back 'Charles' and we use that to start the next query.

2) When we get more records, we always add to the existing set, so it's continually growing, rather than, as it were, 'flipping to the next page'. This is because, as noted below, there are a lot of situations where having most or all the records at once is useful.

3) We have a few cases where we return 100% of the records. Sometimes, the nature of the data is such that we expect never to have more than a few dozen records (for example, if you are a CRM app, depending on your industry, it's not likely that a single user will have more than a couple hundred contacts).

4) There are lots of reasons why it's often convenient to have 100% of the records, or conversely, where having only a small subset prevents you from doing things that seem obvious and simple. These are the source of a huge amount of work and pain and angst in our application, and include:
a) Client-side sorting, eg. clicking a column header to sort by the values in that column.
b) Exporting to other applications, eg. Excel
c) Giving users indicators of the 'you are on row 11 of 138' variety
d) Refreshing, eg. updating a table to indicate the effect of a row that you just added

5) Progress has ProDataSets now (and probably a few other things) that purport to make all of this easier. I am skeptical that this would work for us (I'm a pretty big fan of Progress, but I find their attempts to make hard things simple often have the opposite effect), though my skepticism is largely irrelevant as our code base predates ProDataSets and it's mostly impervious to major architectural changes. None of that shouldn't stop you from reading up on it!

6) As for jQuery, we don't populate tables like that. I'm sure there's nothing wrong with it, but, in our case, all our API's go through a 'gateway' mechanism on both the jQuery and Progress sides that apply a bunch of common security, logging, error handling etc. logic. We have a large amount of code on top of that to format the tables, apply various features (such as in #4 above), and otherwise manipulate the DOM.

7) These days, our infatuation with jQuery is starting to look dubious, as everyone (including the people in our company that set worldwide development standards) seems to think Angular is the way to go. If you're writing a new app and in a position to make that choice, you might consider it. Angular seems several orders of magnitude more complicated than jQuery, and whether the complication is worth it is highly contested on Reddit. Then there's the Angular 2.0 debacle. Of course, Angular isn't the only game in town, though it's starting to feel that way.

HTH!, cheers
Greg
 
Thanks much for the great reply. It is very informative.

Do you have any KB links , Progress documentation Or a small working program to share related to JQuery . So that I can start with a strong base :)

-Philip-
 

GregTomkins

Active Member
I forgot to mention something important. You probably know jQuery has a large plugin community; it includes at least two table plugins, neither of which (AFAIK) deal with your issue directly, but if you are going to be doing serious work with tables in jQuery, you may want to consider them. I tried one, jqGrid, and eventually gave up and wrote my own. The other major alternative that I know of is called DataTables, IIRC; I never tried it.

For me, by far the biggest complication of tables is, of all things, the way the column header bar will scroll off-screen unless you take special measures to prevent it doing so. There are at least three major ways to solve this, I know because I have tried all three in increasingly desperate attempts to make it work in all scenarios and across all major browsers. jqGrid and DataTables both handle this problem, at least in the simple scenario. I have spent countless hours solving this problem in various secondary scenarios, such as column sorting and automatic column width setting.

It's amazing how things you take for granted in the Win32 GUI world can consume endless tracts of time in the browser world. (Of course the opposite is sometimes true as well!).
 
Top