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

	Re: JSON Object to FilteringTable by Jayaram Krishnaswamy :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Some parts of this message have been removed. Learn more about Nabble's security policy. Blank Does the JSON data always need to go through an intermediary store to the filtering table? Does it needs to be converted into an array before populating the table? Is it OK to unpack the object and stuff it into a table like one normaly does populating a table looping through the elements? _______________________________________________ Dojo FAQ: http://dojo.jot.com/FAQ Dojo Book: http://manual.dojotoolkit.org/DojoDotBook Dojo-interest@... http://dojotoolkit.org/mailman/listinfo/dojo-interest Blank Bkgrd.gif (202 bytes) Download Attachment
	Re: JSON Object to FilteringTable by Ross Thomas :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Jayaram Krishnaswamy wrote: Does the JSON data always need to go through an intermediary store to the filtering table? Yes. The store is the repository of the data that is displayed by the FilteringTable. Thus they are essentially a single unit in this context. By manipulating the store you are causing changes to be reflected in the table. Does it needs to be converted into an array before populating the table? Is it OK to unpack the object and stuff it into a table like one normaly does populating a table looping through the elements? The setData() and addDataRange() methods are the most efficient when dealing with multiple updates. If a single object is changed then use the addData() method to add the object or replace it if there is already an entry with the same key. You can use the update() method to update a single field within an element if that is all that changed. All these Store methods invoke events that cause the FilteringTable to update the view accordingly. Thus a sequence of single addData() calls will cause 'n' events. A single addDataRange() call will cause 1 event. Hence the greater efficiency. There is a case for 'chunking' of range updates to maintain UI responsiveness but that is something that is usually discerned on a case by case basis. HTH Ross.
	Re: JSON Object to FilteringTable by Tom Trenka :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Jayaram Krishnaswamy wrote: Does the JSON data always need to go through an intermediary store to the filtering table? Yes. Jayaram Krishnaswamy wrote: Does it needs to be converted into an array before populating the table? Considering that a table is usually a representation of a set of objects in a non-named manner (i.e. an array), yes. Jayaram Krishnaswamy 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? If you want to deal with poor performance, sure. But I think you're confusing generating a string on a server with manipulating a DOM on a client... trt _______________________________________________ Dojo FAQ: http://dojo.jot.com/FAQ Dojo Book: http://manual.dojotoolkit.org/DojoDotBook Dojo-interest@dojotoolkit.org http://dojotoolkit.org/mailman/listinfo/dojo-interest
	Re: JSON Object to FilteringTable by Tom Trenka :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message I should just convince you to write the docs on the widget :) trt Ross Thomas wrote: Jayaram Krishnaswamy wrote: Does the JSON data always need to go through an intermediary store to the filtering table? Yes. The store is the repository of the data that is displayed by the FilteringTable. Thus they are essentially a single unit in this context. By manipulating the store you are causing changes to be reflected in the table. Does it needs to be converted into an array before populating the table? Is it OK to unpack the object and stuff it into a table like one normaly does populating a table looping through the elements? The setData() and addDataRange() methods are the most efficient when dealing with multiple updates. If a single object is changed then use the addData() method to add the object or replace it if there is already an entry with the same key. You can use the update() method to update a single field within an element if that is all that changed. All these Store methods invoke events that cause the FilteringTable to update the view accordingly. Thus a sequence of single addData() calls will cause 'n' events. A single addDataRange() call will cause 1 event. Hence the greater efficiency. There is a case for 'chunking' of range updates to maintain UI responsiveness but that is something that is usually discerned on a case by case basis. HTH Ross.
	Re: JSON Object to FilteringTable by Jayaram Krishnaswamy :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Thanks for the kind answers. I did go to the Dojo API and found similar information. The API documents can be even more powerful if links can be set to usage examples(at least the most common ones). None of the API's(Microsfot,Java,SQLServer etc) I have seen do this, may be there is a reason. ----- Original Message ----- From: "Tom Trenka" <dojo-interest@...> To: <dojo-interest@...> Sent: Thursday, February 01, 2007 6:31 PM Subject: Re: [Dojo-interest] JSON Object to FilteringTable > > I should just convince you to write the docs on the widget :) > > trt > > > Ross Thomas wrote: >> >> >> Jayaram Krishnaswamy wrote: >>> >>> Does the JSON data always need to go through an intermediary store to >>> the >>> filtering table? >>> >> >> Yes. The store is the repository of the data that is displayed by the >> FilteringTable. >> Thus they are essentially a single unit in this context. By manipulating >> the store >> you are causing changes to be reflected in the table. >> >> >> >>> Does it needs to be converted into an array before populating the table? >>> Is it OK to unpack the object and stuff it into a table like one normaly >>> does populating a table looping through the elements? >>> >> >> The setData() and addDataRange() methods are the most efficient when >> dealing >> with multiple updates. If a single object is changed then use the >> addData() method >> to add the object or replace it if there is already an entry with the >> same >> key. >> >> You can use the update() method to update a single field within an >> element >> if that >> is all that changed. >> >> All these Store methods invoke events that cause the FilteringTable to >> update the >> view accordingly. Thus a sequence of single addData() calls will cause >> 'n' events. >> A single addDataRange() call will cause 1 event. Hence the greater >> efficiency. >> >> There is a case for 'chunking' of range updates to maintain UI >> responsiveness but >> that is something that is usually discerned on a case by case basis. >> >> HTH >> >> Ross. >> > > -- > View this message in context: > http://www.nabble.com/Re%3A-JSON-Object-to-FilteringTable-tf3158017.html#a8758989 > Sent from the Dojo mailing list archive at Nabble.com. > > _______________________________________________ > Dojo FAQ: http://dojo.jot.com/FAQ > Dojo Book: http://manual.dojotoolkit.org/DojoDotBook > Dojo-interest@... > http://dojotoolkit.org/mailman/listinfo/dojo-interest > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.411 / Virus Database: 268.17.18/662 - Release Date: 1/31/2007 > > _______________________________________________ Dojo FAQ: http://dojo.jot.com/FAQ Dojo Book: http://manual.dojotoolkit.org/DojoDotBook Dojo-interest@... http://dojotoolkit.org/mailman/listinfo/dojo-interest
	Re: JSON Object to FilteringTable by Ross Thomas :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Tom Trenka wrote: I should just convince you to write the docs on the widget :) Heh! Sorry Tom. Didn't mean to steal your thunder. But you are right. There is a lot of use-based experience out there that would be a great resource if only it could be tapped in a useful way. Wiki's are all well and good, but they are a little disorganized and fall short when trying to reach a distinct goal. As a developer myself I am guilty of the 'code now, document later.' syndrome. :-/ Ross.
	Re: JSON Object to FilteringTable by Tom Trenka :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Actually I was kind of serious about that; I find it to be very instructional when documentation comes from someone who didn't actually write the code but seems to know it pretty well. And we're working on the suggestion. trt Ross Thomas wrote: Tom Trenka wrote: I should just convince you to write the docs on the widget :) Heh! Sorry Tom. Didn't mean to steal your thunder. But you are right. There is a lot of use-based experience out there that would be a great resource if only it could be tapped in a useful way. Wiki's are all well and good, but they are a little disorganized and fall short when trying to reach a distinct goal. As a developer myself I am guilty of the 'code now, document later.' syndrome. :-/ Ross.
	Re: JSON Object to FilteringTable by Sasha Firsov :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Some parts of this message have been removed. Learn more about Nabble's security policy. It would be different from you seen in guru answers... Jayaram wrote: Blank 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. 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) Rest fields could be added by store.update(Object obj, string fieldName, Object fieldVal) 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. Sasha _______________________________________________ Dojo FAQ: http://dojo.jot.com/FAQ Dojo Book: http://manual.dojotoolkit.org/DojoDotBook Dojo-interest@... http://dojotoolkit.org/mailman/listinfo/dojo-interest
	Re: JSON Object to FilteringTable by Tom Trenka :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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
	Re: JSON Object to FilteringTable by ibsscott :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message It would seem to me that there should be a method to add row(s) based on HTML and having a function auto-convert it to JSON as you described. 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. 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
	Re: JSON Object to FilteringTable by Sasha Firsov :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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
	Re: JSON Object to FilteringTable by Ross Thomas :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Tom Trenka wrote: Actually I was kind of serious about that; I find it to be very instructional when documentation comes from someone who didn't actually write the code but seems to know it pretty well. Well, I have a deadline looming that is taking most of my time these days (hence the low response flow to the list). I could certainly give it a shot after that. Is there a preferred/official documentation style? And we're working on the suggestion. I assume this is part of the ongoing discussions the core group is having. Should be interesting once it sees the light of day. Ross.
	Re: JSON Object to FilteringTable by Tom Trenka :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Nothing yet, and there are some fairly extensive changes coming up. But after that, it would be helpful to know that we could ask for documentation help efforts... trt Ross Thomas wrote: Tom Trenka wrote: Actually I was kind of serious about that; I find it to be very instructional when documentation comes from someone who didn't actually write the code but seems to know it pretty well. Well, I have a deadline looming that is taking most of my time these days (hence the low response flow to the list). I could certainly give it a shot after that. Is there a preferred/official documentation style? And we're working on the suggestion. I assume this is part of the ongoing discussions the core group is having. Should be interesting once it sees the light of day. Ross.