> 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.
I haven't figured out how to use remote models and be able to use cell
editors yet. Every example that has cell editors uses
tableModel.setColumnEditable(columnIndex, bool) method. This method is
avaiable just in the Simple Model Class.
What am I missing?
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
