> I guess this is the fastest adoption of a widget ever :-)
is there some kind of award for that? maybe a t-shirt :P
just kidding :-)
2008/7/30 thron7 <[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]>:
> >
> >> 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
>
-------------------------------------------------------------------------
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
