server-side paging, client side assignment of colums - looking for best approach

server-side paging, client side assignment of colums - looking for best approach

asiandubasiandub Posts: 3Questions: 0Answers: 0
edited March 2012 in General
Hi everyone,

in our not-so-small application we need to switch some tables to server-side paging. Our displayed entity is called "product", and we have various tables with various sortings, filterings and views, most of them are displaying products.

I played with server-side paging, and it looks pretty promising :-)

But I'm still having an issue with the server component: Currently I need a piece of server-side code per table, which fills "aaData" with the query result, and therefore needs knowledge about which table column displays which data. This approach feels too static for our application, we have a lot of tables, and I'd prefer to keep the whole table thing on the client side. Especially, as all existing formatting and localisation logic resides on the client.

Ideally, the server would just return the correct list of products and the client chooses which columns to display (on a static per-table base, of course). Sorting should still be supported, if possible.

What would be the best approach for this?

Thx,
Jan

Replies

  • asiandubasiandub Posts: 3Questions: 0Answers: 0
    After some try-and-error, I ended up with sending a fully initialised array - which is completely empty except a JSON-ized product in column[0].

    On the client-side, I initially read the product from column[0] and fill all other columns from within the same fnRender-function:

    [code]
    [
    { "fnRender": function ( o, val ) {
    var product = o.aData[0];
    o.aData[0] = product.someData();
    o.aData[1] = product.someOtherData();
    o.aData[2] = product.someData();
    ...
    o.aData[15] = product.someData();
    return o.aData[0]
    }},
    null, null,null, null,null, null,null, null,null, null,null, null,null, null, null
    ]
    [/code]
    (array is set as aoColumns)

    I simplified the code a bit, but what matters is that:
    - all tables call the same server-API and get the same data-structure in return
    - the server-side code is not dependent from any table
    - all existing L16N and I18N client-side code can be reused.

    Thoughts & comments are welcome :-)

    Cheers,
    Jan
  • allanallan Posts: 63,205Questions: 1Answers: 10,415 Site admin
    Looks good!

    I'm going to do some work soon to try and get fully dynamic columns working - possibly for v1.10 which will hopefully make somethings like this easier, but this looks like a good approach to me at the moment.

    Allan
  • asiandubasiandub Posts: 3Questions: 0Answers: 0
    edited March 2012
    Thanks Allan! I'm looking forward to next release - this is really great work of yours.

    One more observation I just made: It seems as if this approach confuses the autoWidth option. I'll get some error messages if I try to enable it...
This discussion has been closed.