Subject: dojo.data - simple paging example - msg#00013

Previous Message by Date: click to view message preview

Re: [Dojo-escalate] bug in dojo.lang declare

Yep. That's what I'll do. My original code used "hook" methods, which are called from a base class, but implemented in derived classes. This approach doesn't scale logically, cumbersome, and error-prone. That's why I wanted to get rid of it, but got stuck in dojo.declare limitations. And I *really* love dojo.declare. :-( Thanks, Eugene On 10/1/06, Jesse Kuhnert <jkuhnert@xxxxxxxxx> wrote: You could also just use the prototype reference directly. Besides being much faster than anything we can do dynamically, it has the added benefit of being easily understood by anyone who is familiar with "built in" javascript language features. For gfx especially I would think you'd want to try and keep everything as tight/performant as is reasonably possible. imho.. On 10/1/06, Scott J. Miles <sjmiles@xxxxxxxxxxxxx> wrote: > This "bug" has been posted many times. It's not a bug. You cannot call into > a superclass method that uses "inherited" from a method that was invoked by > "inherited". It does not work that way, never has, never was intended to. > "inherited" is just a slight enhancement of the "superclass" simplification. > > Your fix works for your test case but breaks the actual intended > functionaliy of "inherited" which is to be able to call a series of > ancestral methods, e.g. "fillInTemplate". > > Dojo.declare is not designed to make JS into C++/Java/Other OOP language. > It's only a facility to build JS constructors with common boilerplate. > > There are various solutions out there for the kind of functionality you are > looking for, but IMO they are too invasive. The "inherited" I included has > no impact on the normal usage of the objects. > > Regards, > Scott J. Miles > TurboAjax Group > http://www.turboajax.com > > > > -----Original Message----- > > From: dojo-escalate-bounces@xxxxxxxxxxxxxxx > > [mailto: dojo-escalate-bounces@xxxxxxxxxxxxxxx] On Behalf Of > > Eugene Lazutkin > > Sent: Sunday, October 01, 2006 9:21 AM > > To: dojo-escalate@xxxxxxxxxxxxxxx > > Subject: [Dojo-escalate] bug in dojo.lang declare > > > > Today I found a bug in otherwise excellent dojo.declare > > facility. I want this bug to be resolved quickly (it breaks > > dojo.gfx at the moment), and I don't feel it is a change I > > should do on my own => I escalate it. > > > > The bug manifests itself in following case: > > > > dojo.declare("X", Base, { > > a: function() { > > dojo.debug("X.a"); > > }, > > b: function() { > > dojo.debug("X.b"); > > this.a(); > > } > > }); > > > > dojo.declare("Y", Base, { > > a: function() { > > dojo.debug ("Y.a"); > > this.inherited("a", []); > > }, > > b: function() { > > dojo.debug("Y.b"); > > this.inherited("b", []); > > } > > }); > > > > var t = new Y(); > > t.b(); > > > > The last call has to print all 4 messages. In fact it prints only 3 > > --- X.a is never called. It appears that the culprit is > > dojo.lang.declare.base._getPropContext () --- it returns > > either this.___proto or this, which breaks a search loop in > > dojo.lang.declare.base.inherited(): the latter case should be > > processed with do{}while() loop, but the former (with > > ___proto) should be processed with while(){} loop (we should > > search right away). > > > > My patch, which fixes the problem for me, is below: > > > > Index: declare.js > > =================================================================== > > --- declare.js (revision 5921) > > +++ declare.js (working copy) > > @@ -136,12 +136,18 @@ > > }, > > // searches backward thru prototype chain to find > > nearest ancestral instance of prop > > inherited: function(prop, args){ > > - var p = this._getPropContext(); > > + var p = this; > > do{ > > - > > if((!p.constructor)||(!p.constructor.superclass)){return;} > > - p = p.constructor.superclass; > > + if(p.___proto){ > > + p = p.___proto; > > + }else if(p.constructor && > > p.constructor.superclass){ > > + p = p.constructor.superclass; > > + }else{ > > + return; > > + } > > }while(!(prop in p)); > > return (dojo.lang.isFunction(p[prop]) ? > > this._inherited(p, prop, > > args) : p[prop]); > > + > > } > > } > > > > Basically I removed a call to _getPropContext, and slightly > > modified the search loop, including a test for ___proto in > > it. I cannot tell, if it can break something else, but it > > works for me. > > > > Please assess the problem ASAP --- it prevents me from > > checking in the latest refactored dojo.gfx code, and possibly > > affects some code out there. > > > > Thanks, > > > > Eugene > > > > -- > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.1.407 / Virus Database: 268.12.10/459 - Release Date: 9/29/2006 > > > _______________________________________________ > Dojo-escalate mailing list > Dojo-escalate@xxxxxxxxxxxxxxx > http://dojotoolkit.org/mailman/listinfo/dojo-escalate > -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com _______________________________________________ Dojo-escalate mailing list Dojo-escalate@xxxxxxxxxxxxxxx http://dojotoolkit.org/mailman/listinfo/dojo-escalate

Next Message by Date: click to view message preview

Re: dojo.data - simple paging example

We've been talking about what the datastore API should look like for that use case. One option is for the GUI code make separate calls to store.find() each time the user pages forward, with each call getting a new result object, one result object per page of data. Another option is for the the GUI code make one initial call to store.find() to get a single result object, and then make separate calls to result.forEach(), each time asking to loop over just a portion of the virtual result set. The question is, should we encourage just that first option, or just the second, or allow for both? I'm not opposed to having both options, but I like the single-result set approach presented here. In writing these sorts of apps, especially with async queries, it seems like it would be advantageous to have a single result set that the app author deals with rather than having to manage multiple sets. For example, it's pretty common to load data in bigger chunks than you want to display -- that way "next page" can be instantaneous (although the next page after *that* may take a while -- we take what we can get). Presumably, it should be pretty easy to make a display- tabley-widget thing that could implement this automatically -- whenever it displays a page, it goes and fetches the data for the next page in the background. Or you might be able to teach your tabley-widget that some items may be in memory, while some aren't. So if you have half of the next page of things, it displays the half that it has, with a little "loading..." message for the ones it can't find yet. Then when those load, their loading messages replaced in the table with real data. This type of thing is great for UI, because the user can see that something is happening immediately, and results can come back in as they are ready. It seems like the single result set is almost a must for the "infinite scrollbar" case -- managing multiple result sets would be a real pain. There is another UI paradigm that this is also great for -- where you start with a small table (say 10 items), then the last item says "more...". They click the button and those items load underneath the set already present. I did a quick mockup of that [can you tell I'm procrastinating?], enclosed -- drop the files in the same folder as Brian's example to see it. Finally, one thing that I'd expect to see in the params available to the method forEach() calls is the index in the result set of the item being iterated on. Without this, I was dependent on the server setting the "identity" column. If it doesn't make sense to pass it as a parameter to the function, perhaps there can be a flag that indicates that an index should appear in the result set data? Fun stuff! cheers O additive_paging.zip Description: Zip archive ------------------------- Whenever I despair, I remember that the way of truth and love has always won. There may be tyrants and murderers, and for a time, they may seem invincible, but in the end, they always fail. Think of it: always. -- Mohandas K. Ghandi On Oct 1, 2006, at 6:49 PM, Brian Douglas Skinner wrote: For people intested in the dojo.data design... We've been talking about how we want scrolling and paging to work for large result sets. If there's a large result set, the UI might allow the user to go from page to page through the results. Or the UI might have a large scroll-view, and incrementally load data as the user scrolls. As a quick exercise to make all of this more concrete, this weekend I wrote some test code that uses the second option (one result object and multiple calls to result.forEach()). The test code uses the Yahoo web services APIs to run a Yahoo query, and then you can page through the results. I'm including the code as an attachment here, if you want to play around with it. To use it, first create a new "yahoo" folder in your dojo tests/data directory: trunk/tests/data/yahoo Unzip the attachment, drop the contents into the yahoo folder, and open the "paging_example.html" file. If you're looking at the code, the place to start is paging_example.js. There's a method runSearch(), which has the call to store.find(), and there's a method displayPage(), which has the call to result.forEach(). Let me know if you run into problems, and I can try sending the files in some other format. :o) Skinner <paging_example.zip> _______________________________________________ dojo-contributors mailing list dojo-contributors@xxxxxxxxxxxxxxx http://dojotoolkit.org/mailman/listinfo/dojo-contributors _______________________________________________ dojo-contributors mailing list dojo-contributors@xxxxxxxxxxxxxxx http://dojotoolkit.org/mailman/listinfo/dojo-contributors

Previous Message by Thread: click to view message preview

test ready

I'm sure I probably screwed something up or something, but the previously mentioned benchmarking test has been created under tests/lang/test_declar_benchmark.html. Please feel free to modify it / change things to whatever anyone thinks is a good comparison. It's probably best that people just run the tests themselves instead of me trying to figure out anything definitive...There are other factors other than speed to consider(as well as the fact that I may have screwed something up ;) ), so maybe at the very least this will serve as a platform to "play with things" when we have time. -- Jesse KuhnertTapestry/Dojo/(and a dash of TestNG), team member/developerOpen source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com _______________________________________________ dojo-contributors mailing list dojo-contributors@xxxxxxxxxxxxxxx http://dojotoolkit.org/mailman/listinfo/dojo-contributors

Next Message by Thread: click to view message preview

Re: dojo.data - simple paging example

We've been talking about what the datastore API should look like for that use case. One option is for the GUI code make separate calls to store.find() each time the user pages forward, with each call getting a new result object, one result object per page of data. Another option is for the the GUI code make one initial call to store.find() to get a single result object, and then make separate calls to result.forEach(), each time asking to loop over just a portion of the virtual result set. The question is, should we encourage just that first option, or just the second, or allow for both? I'm not opposed to having both options, but I like the single-result set approach presented here. In writing these sorts of apps, especially with async queries, it seems like it would be advantageous to have a single result set that the app author deals with rather than having to manage multiple sets. For example, it's pretty common to load data in bigger chunks than you want to display -- that way "next page" can be instantaneous (although the next page after *that* may take a while -- we take what we can get). Presumably, it should be pretty easy to make a display- tabley-widget thing that could implement this automatically -- whenever it displays a page, it goes and fetches the data for the next page in the background. Or you might be able to teach your tabley-widget that some items may be in memory, while some aren't. So if you have half of the next page of things, it displays the half that it has, with a little "loading..." message for the ones it can't find yet. Then when those load, their loading messages replaced in the table with real data. This type of thing is great for UI, because the user can see that something is happening immediately, and results can come back in as they are ready. It seems like the single result set is almost a must for the "infinite scrollbar" case -- managing multiple result sets would be a real pain. There is another UI paradigm that this is also great for -- where you start with a small table (say 10 items), then the last item says "more...". They click the button and those items load underneath the set already present. I did a quick mockup of that [can you tell I'm procrastinating?], enclosed -- drop the files in the same folder as Brian's example to see it. Finally, one thing that I'd expect to see in the params available to the method forEach() calls is the index in the result set of the item being iterated on. Without this, I was dependent on the server setting the "identity" column. If it doesn't make sense to pass it as a parameter to the function, perhaps there can be a flag that indicates that an index should appear in the result set data? Fun stuff! cheers O additive_paging.zip Description: Zip archive ------------------------- Whenever I despair, I remember that the way of truth and love has always won. There may be tyrants and murderers, and for a time, they may seem invincible, but in the end, they always fail. Think of it: always. -- Mohandas K. Ghandi On Oct 1, 2006, at 6:49 PM, Brian Douglas Skinner wrote: For people intested in the dojo.data design... We've been talking about how we want scrolling and paging to work for large result sets. If there's a large result set, the UI might allow the user to go from page to page through the results. Or the UI might have a large scroll-view, and incrementally load data as the user scrolls. As a quick exercise to make all of this more concrete, this weekend I wrote some test code that uses the second option (one result object and multiple calls to result.forEach()). The test code uses the Yahoo web services APIs to run a Yahoo query, and then you can page through the results. I'm including the code as an attachment here, if you want to play around with it. To use it, first create a new "yahoo" folder in your dojo tests/data directory: trunk/tests/data/yahoo Unzip the attachment, drop the contents into the yahoo folder, and open the "paging_example.html" file. If you're looking at the code, the place to start is paging_example.js. There's a method runSearch(), which has the call to store.find(), and there's a method displayPage(), which has the call to result.forEach(). Let me know if you run into problems, and I can try sending the files in some other format. :o) Skinner <paging_example.zip> _______________________________________________ dojo-contributors mailing list dojo-contributors@xxxxxxxxxxxxxxx http://dojotoolkit.org/mailman/listinfo/dojo-contributors _______________________________________________ dojo-contributors mailing list dojo-contributors@xxxxxxxxxxxxxxx http://dojotoolkit.org/mailman/listinfo/dojo-contributors