Guilherme Aiolfi schrieb: > > I guess this is the fastest adoption of a widget ever :-) > > is there some kind of award for that? maybe a t-shirt :P
Do you want some candy as well? Best Fabian > > just kidding :-) > > 2008/7/30 thron7 <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> > > 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] > <mailto:[EMAIL PROTECTED]>>: > > > >> On Tue, Jul 29, 2008 at 3:52 PM, Guilherme Aiolfi > <[EMAIL PROTECTED] <mailto:[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=/ > <http://moblin-contest.org/redirect.php?banner_id=100&url=/> > >> _______________________________________________ > >> qooxdoo-devel mailing list > >> qooxdoo-devel@lists.sourceforge.net > <mailto: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=/ > <http://moblin-contest.org/redirect.php?banner_id=100&url=/> > > _______________________________________________ > > qooxdoo-devel mailing list > > qooxdoo-devel@lists.sourceforge.net > <mailto: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=/ > <http://moblin-contest.org/redirect.php?banner_id=100&url=/> > _______________________________________________ > qooxdoo-devel mailing list > qooxdoo-devel@lists.sourceforge.net > <mailto: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 > -- Fabian Jakobs JavaScript Framework Developer 1&1 Internet AG Brauerstraße 48 76135 Karlsruhe Amtsgericht Montabaur HRB 6484 Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Oliver Mauss, Achim Weiss Aufsichtsratsvorsitzender: Michael Scheeren ------------------------------------------------------------------------- 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
