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
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
