Petr Kobalíček wrote: > Darrel, > > your answer is great. I thing that similar answers should be directly > added to documentation ;-) >
+1 Derrell, don't let it fade to electronic sediment... ;-) T. > 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 > > > ------------------------------------------------------------------------- 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
