Re: JSON Object to FilteringTable

Tom,
Hmm, it is coming personal. In general, personal notes shall be outside of newsgroup.
In posts I am giving alternative OPTIONS. They are not best ( what IS pointed) but have a reason to exist. Unlike others, I am not pointing to ONLY way of use. Let user decide what is easies and appropriate for it`s task. You are shown only one side, which is limited.
I am able to provide dozen examples, where it will be absurd to use JSON for filling FilteringTable.
inline...

Tom Trenka wrote:

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.
  

You are spoken on behalf of FilteringTable. I was pointing from user`s prospective. FilteringTable is black box for most. Internals are not interested until it conflicts with requirements (performance or design, etc).
So user still have the option to work with FilteringTable without JSON on his side. Is it?

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.
  

It would be correct for HEAVY data set. The *heavy* depends of product requirements.
Usually, few rows could be filled without ANY performance impact. Such use is not best, not recommended, but still totally valid.

In *another* use case, when FilteringTable modified dynamically( right, incrementally), it is even recommended. Is it?

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.
  

That is internals, who cares if existing method works?

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?
  

Field in table you mean. If field not exist (undefined in object), it will be created. The bug fix patch has been proposed, but struggled to get through :))

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
  

Sorry to tell, but performance IS one of major criteria in my dev-t. Another thing, how to keep it well.
My point that performance is a balance, you pay the price for it. Development time is one of those expenses.
Reusable component/lib shall be aware of both: performance AND development time(read easy/flexible use).
So far I have not proposed ANYTHING what could compromise the performance. If proposed method slowing app, it IS STATED. User still have an option (note, DEFAULT one!) not to use the heavy one.

I DO value your awareness for performance and other aspects. It would be a shame on me otherwise.
Next time I will pay more attention in explaining WHY there is no performance compromised.
Please, be more precise when throw accusation "like yourself, don't care about it." This at least is not polite.
All of your statements about my performance-related assumptions simply are not true. If you do not know them, it not gives you right to blame.

I guess, community will forgive us for rude behavior in public space. Hope, in very end it will lead to better and useful code.

Sasha


_______________________________________________
Dojo FAQ: http://dojo.jot.com/FAQ
Dojo Book: http://manual.dojotoolkit.org/DojoDotBook
Dojo-interest@...
http://dojotoolkit.org/mailman/listinfo/dojo-interest