Darrel, your answer is great. I thing that similar answers should be directly added to documentation ;-)
2008/7/29 Derrell Lipman <[EMAIL PROTECTED]>: > On Tue, Jul 29, 2008 at 3:52 PM, Guilherme Aiolfi <[EMAIL PROTECTED]> wrote: >> >> Hi, > > Hi! > >> >> I'm keep doing some tests, now with tables. > > Great. The message subject indicates that you're using 0.8 but I believe > from your questions that that's not actually the case. Please confirm that > you're actually using 0.7.x (either a release or the legacy_0_7_x branch in > svn). Fabian is *just now* finishing up porting Table to 0.8, so it's > highly unlikely that it's yet stable enough to be testing with. And I don't > believe that Progressive has yet been ported to 0.8 at all. >> >> First, I would like to know the difference between Virtual Table and >> Progressive Table. ohh, and a simple Table using a Remote model. > > qx.ui.table.* is a very powerful widget. It is "virtual" in that the table > data can be of any length (e.g. hundreds of thousands of rows or more) yet > only the rows which are actually being viewed are rendered. As the user > scrolls up or down, the rendered rows are removed and the newly visible rows > are rendered in their place. Rendering a large amount of data is a very, > very slow operation, so being able to render only the visible rows has HUGE > benefits. You'll sometimes hear qx.ui.table.* referred to as simply "Table" > and sometimes as "Virtual Table". Those terms reference the same widget in > qooxdoo. > > The data supplied to (and displayed by) the Table widget can be entirely > resident in memory at the browser or can be fetched from a "backend" (web > server) as it is needed to be displayed (and some can be pre-fetched too). > The data model you choose determines where and how the data is retrieved > from. qx.ui.table.model.Simple provides a simple (duh!) model in which all > of the table data resides in memory at the browser; i.e. the whole data set > is resident as an array of arrays in the Simple data model. Alternatively, > qx.ui.table.model.Remote allows the data to be fetched from the backend as > it is needed. qx.ui.table.model.Remote is an abstract class that you can > extend by providing the actual communication to your backend. > > As powerful as the Table widget is, there are some drawbacks to the virtual > aspects of it. One big one is that it is very difficult to implement > scrolling in a virtual widget when the rows are not the same height. For > that reason, to date, Table has required that the row height be a constant > for any particular table. (I don't know if Fabian is working to remove this > restriction in the 0.8 port.) For those times that you'd really like to > have variable row height, qx.ui.Progressive provides a table renderer that > lets you do that. Progressive is a nice general-purpose widget that can do > things progressively. The examples show how it can be used to progressively > build your gui so that the user sees it progressively being built, i.e. > instead of just waiting for a while until the whole gui has been built up > and then it gets displayed, loading with Progressive allows individual or > groups of widgets to be rendered as they are ready even though the entire > gui has not yet been built. Another renderer available with Progressive is > the table renderer. It allows you to have a fairly large table get does > ultimately get rendered in its entirety to the browser, but does so > progressively so that the user can begin to work with the page and the data > that has already been rendered even though more table data is still being > rendered. > > If the (few) limitations of Table don't effect what you're trying to do, > it's likely that qx.ui.table.* is the preferable widget to use for table > rendering. If you need variable row height, then consider Progressive's > table renderer, and consider Progressive whenever you would like for the > user to see a sequence of things happening rather than waiting for all of > them to complete before seeing anything on the screen. > >> >> Second, can I use cell editors with a remote model? is there an example? > > The examples would be the same as with the Simple model, as the cell editor > communication is with the model. If you implement the methods by the > abstract Remote model class, you should have use of cell editors with no > other work. >> >> and, the last question: >> >> ERROR: >> >> args.callee.base is undefined >> base()([qx.event.type.Event[ic] $$hash=ic _type=disappear], >> undefined)Object.js (linha 128) >> _onDisappear()()Scroller.js (linha 653) >> _dispatchEvent()(qx.event.type.Event[7q] $$hash=7q _type=disappear >> _target=div)EventHandler.js (linha 230) >> dispatchEvent()(div, qx.event.type.Event[7q] $$hash=7q _type=disappear >> _target=div, "disappear")Direct.js (linha 100) >> wrappedFunction()Interface.js (linha 352) > > It's quite difficult to have any idea what's going on here because (a) you > sent a backtrace from a "build" version, not a "source" version; and (b) you > didn't send enough code to locate the problem. The best thing to do when > asking for help of this type is to build a very small test application based > on the skeleton, that shows the bug. Post that application and someone will > likely be able to point out the errors of your way. > > Cheers, > > Derrell > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > qooxdoo-devel mailing list > qooxdoo-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
