I Agree with Anatoly.
It solely depends on your requirements. Initially when i was doing the grids
in my UI i used jqgrid which worked great for couple of hundreds of
records(data was passed as JSON). But as mentioned below if the data is
really too much most of the time would be spent in parsing the data through
javascript and i did see the problem when i was trying to scale the
application and customers started complaining about it.

Few things i did to resolve the problem. First i used the scroll capture
technique that is used by yahoo mail where they calculate the scroll height
and have a div besides it which does some pagination calculation and calls
the backend to get the content of that page.

The most useful solution i found is to ask the user how many records they
want to display, i put the limit to 100 records, then i
started pre-rendering  the contents of the very first call in the backend
with jstl/jsps, with the grid showing 100 records, i provided pagination to
navigate (using ajax) which just get the html contents straight from the
backend and inject the html in the container rather then getting the json
and parsing it and then rendering it.

I found it to be much more efficient considering user experience and
performance on the front end side. Lastly having tables in the page is not a
bad idea at all but having too many tables in the page is slow, this might
not be true with the modern browsers but if you are considering supporting
IE7 (which i think you are) then you might see performance degradation.

Varun

On Wed, Jun 29, 2011 at 9:08 AM, Anatoly Geyfman <[email protected]>wrote:

> I think you should get a little further and ask questions when issues come
> up. The only thing I can recommend to you right now is to download only the
> data you need - if you receive too much data from the server (let's say
> >200k JSON), your browser may lock up for a moment parsing that data. For
> slower machines, that moment may be much longer.
>
> A
>
> 2011/6/29 Andrés Maneiro <[email protected]>
>
>> I've played a bit more with jquery building a very simple example to test
>> my thoughts. The task seems easy to build following the approach described:
>>
>> https://gitorious.org/amaneiro-scripts/amaneiro-scripts/commit/a8eb1aa86dbc199d41dc8ce38a717b3b86a0be03
>>
>> Em 29 de junho de 2011 12:45, Andrés Maneiro 
>> <[email protected]>escreveu:
>>
>> Hello,
>>>
>>> I'm starting to develop a simple webpage intensive in data. Let me
>>> explain a bit what I need:
>>>
>>> - The front-end will be a simple webpage with several tables and one
>>> combobox. The values in the tables will change depending on the value
>>> selected in the combobox.
>>> - The data is in a database, which I plan to process previously to
>>> generate a JSON file with all data I'm interested in. That file will contain
>>> all the values of the tables (for each variable in the combobox) and will be
>>> given along the HTML. My initial though is to tie the JSON data-model to the
>>> design of the tables.
>>> - Finally, I would glue together the HTML and the JSON with javascript. I
>>> suppose this have to be simple as the data-model will reflect the structure
>>> of the tables.
>>>
>>> That way I would have a simple webpage data-intensive which no require
>>> queries to the server or the database. I've looking very simple examples on
>>> jquery and it seems to fit well for this job [1]. But, assuming that the
>>> requirements above are very common in a web application plus I need some
>>> complex data-model (which could vary while I develop it), I'd like to hear
>>> from your experiences doing so: would you use other approach? Some better
>>> library which fits better?
>>>
>>> best,
>>> amaneiro
>>>
>>> [1]
>>> http://api.jquery.com/data/
>>>
>>> http://elegantcode.com/2009/07/01/jquery-playing-with-select-dropdownlistcombobox/
>>>
>>>
>>  --
>> To view archived discussions from the original JSMentors Mailman list:
>> http://www.mail-archive.com/[email protected]/
>>
>> To search via a non-Google archive, visit here:
>> http://www.mail-archive.com/[email protected]/
>>
>> To unsubscribe from this group, send email to
>> [email protected]
>>
>
>  --
> To view archived discussions from the original JSMentors Mailman list:
> http://www.mail-archive.com/[email protected]/
>
> To search via a non-Google archive, visit here:
> http://www.mail-archive.com/[email protected]/
>
> To unsubscribe from this group, send email to
> [email protected]
>



-- 
Varun Aggarwal

-- 
To view archived discussions from the original JSMentors Mailman list: 
http://www.mail-archive.com/[email protected]/

To search via a non-Google archive, visit here: 
http://www.mail-archive.com/[email protected]/

To unsubscribe from this group, send email to
[email protected]

Reply via email to