Re: JSON Object to FilteringTable

Dude,
Would you mind actually *looking* through the code at some point before giving someone inaccurate answers?  Allow me to debunk inline.

Sasha Firsov wrote:

It would be different from you seen in guru answers...

Jayaram wrote:

Does the JSON data always need to go through an intermediary store to the filtering table?

No. You can fill the HTML in table and NO JSON will be involved at all.

This is actually incorrect, though I can see where you might think that...the reality is that there are 2 ways of populating a FilteringTable: via JSON, and by simply turning a straight HTML table into the widget.  *However*, if you use the second method, the widget will, on initialization (essentially in .postCreate), *convert* all of the data in the HTML table to a JSON array and use it to populate the underlying Store object.  The converter is actually a static method of the Store, you can see it for yourself.

Sasha Firsov wrote:

Jayaram wrote:

Does it needs to be converted into an array before populating the table?

NO. Even if it is still good idea to use an array, you are able to fill table store one by one object, which still need to have key field. store.addData(obj obj, string key)

I would *highly* suggest that you *don't* fill out a table that way; that method is meant for incremental updates and not for populating wholesale.  There is a reason for .setData and .addDataRange; use it, and use an array.

Again, the reality is that the default init procedure will, in the very least, create a Store with an empty array as the inner list.

Sasha Firsov wrote:

Rest fields could be added by store.update(Object obj, string fieldName, Object fieldVal)

That method is meant for existing fields.  You know, like UPDATE in SQL?

Sasha Firsov wrote:

Jayaram wrote:

Is it OK to unpack the object and stuff it into a table like one normaly does populating a table looping through the elements?

Not sure what you mean. You can fill the table HTML on server as table row content. The data will be parsed and available in JS via store.

While I do appreciate your responses it's becoming apparent that you don't really consider performance to be a concern, whereas you really should.  There are a lot of limitations to working with tables in HTML--let alone add additional functionality via JS--and making blanket assumptions about performance is really not an option in JS...unless you think that others using your code, like yourself, don't care about it.  I'd suggest that's a really bad attitude to have; once you start to factor in performance, you'll start to understand some of the decisions I made in writing that widget, and a good portion of decisions other contributors have made throughout Dojo.

trt