[0.8] Tables

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[0.8] Tables

Krycek
Hi,

I'm keep doing some tests, now with tables.

First, I would like to know the difference between Virtual Table and Progressive Table. ohh, and a simple Table using a Remote model.

Second, can I use cell editors with a remote model? is there an example?

and, the last question:

ERROR:

args.callee.base is undefined
_onDisappear()()Scroller.js (linha 653)
wrappedFunction()Interface.js (linha 352)
refresh()()Appear.js (linha 183)
refresh()()Appear.js (linha 101)
flush()()Element.js (linha 368)
flush()()Manager.js (linha 117)
wrappedFunction()Interface.js (linha 352)
fireEvent()(Window index.html, "useraction", undefined, undefined)Registration.js (linha 242)
__fireEvent()(dblclick clientX=75, clientY=151, "dblclick", label)Mouse.js (linha 168)
(?)()(dblclick clientX=75, clientY=151)Function.js (linha 378)
 return args.callee.base.call(this);


I'm just getting this error when I try to create a skeleton.view.FirstView (extends qx.ui.tabview.Page) that contains a toolbar and a table. The weird thing is that this error only happen the second time the class is instancied (or the second tab is created, the second tab being exactly the same as the fisrt one).

Without the following code, the error doesn't occour (skeleton.view.FirstView):

            var rowData = this.createRandomRows(50);
          
            var tableModel = this._tableModel = new skeleton.model.FirstModel();

            tableModel.setColumns(["ID", this.tr("A number"), this.tr("A date"), this.tr("Boolean")]);
            var table = new qx.ui.table.Table(tableModel);
            table.getSelectionModel().setSelectionMode(qx.ui.table.selection.Model.MULTIPLE_INTERVAL_SELECTION);        
            var tcm = table.getTableColumnModel();
            tcm.setDataCellRenderer(3, new qx.ui.table.cellrenderer.Boolean());
            return table;


skeleton.model.FirstModel() extends qx.ui.table.model.Remote (but the error occours using qx.ui.table.model.Simple() too, so I guess it's not the model).


-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: [0.8] Tables

Derrell Lipman
On Tue, Jul 29, 2008 at 3:52 PM, Guilherme Aiolfi <[hidden email]> 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

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: [0.8] Tables

Krycek
What a great explanation. Thank you for that.

Actually, I'm using the 0.8. But I've asked about the cell editor because even in the qx.ui.table.model.Remote 0.7.3 API, there aren't those method used in the example here.

And all examples here show table using Simple model. Where can I find other examples? including examples of progressive's widgets.

The error shows the backtrace from "source" and not from "build" (at least all I'm doing until know is using "make source", "make build" doesn't work: ImportError: No module named tree... but that's another history). And I guess I'll wait until the beta1 came out to do a test case to report these bug (if they are really bugs).


2008/7/29 Derrell Lipman <[hidden email]>
On Tue, Jul 29, 2008 at 3:52 PM, Guilherme Aiolfi <[hidden email]> 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

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: [0.8] Tables

Petr Kobalíček
In reply to this post by Derrell Lipman
Darrel,

your answer is great. I thing that similar answers should be directly
added to documentation ;-)

2008/7/29 Derrell Lipman <[hidden email]>:

> On Tue, Jul 29, 2008 at 3:52 PM, Guilherme Aiolfi <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: [0.8] Tables

Derrell Lipman
In reply to this post by Krycek


On Tue, Jul 29, 2008 at 5:12 PM, Guilherme Aiolfi <[hidden email]> wrote:
What a great explanation. Thank you for that.

You're welcome.
 

Actually, I'm using the 0.8.

LOL.  Wow, you really like to live at the cutting edge.  No, that's not just cutting, that's bleeding (as in gushing blood!) :-)  Fabian's been checking in changes today, Jonathan checked in more changes since you posted.  It's still actively being developed.  As to your crash... uh... how about we wait until the code is stable before debugging that. :-)
 
But I've asked about the cell editor because even in the qx.ui.table.model.Remote 0.7.3 API, there aren't those method used in the example here.

That's correct.  The example you reference does not use a Remote data model.  If you look at line 187, it's creating a new qx.ui.table.model.Simple.  But like I said, the cell editors are not specific to a data model.  The model's setValue() method gets called by the table code when you close a cell editor.  If you look at Remote.js, you'll see that its setValue() method fires an EVENT_TYPE_DATA_CHANGED event.  Your subclass of Remote would presumably catch that event and send the changed data up to your backend.  In the Simple model, the value is simply saved locally.

And all examples here show table using Simple model. Where can I find other examples? including examples of progressive's widgets.

AFAIK, there are currently no examples of using the Remote model.  The problem is that there is no backend running on the qooxdoo site, so there's nothing for it to talk to.  I thought I had seen an example of a Remote model that actually talked to itself to demonstrate how to implement the required methods, but I can't find that now.

As to Progressive, the demos have not made it to the web site for some reason.  If you check out the legacy_0_7 branch, though, you'll find  these in demobrowser:

example/ProgressiveLoader_1.html
example/ProgressiveTable_1.html
example/ProgressiveTable_2.html
example/ProgressiveTable_3.html
example/ProgressiveTable_4.html
example/ProgressiveTable_5.html
example/ProgressiveTable_6.html

Hope that helps.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: [0.8] Tables

Fabian Jakobs
Administrator
Good morning ererybody,

> On Tue, Jul 29, 2008 at 5:12 PM, Guilherme Aiolfi <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     What a great explanation. Thank you for that.
>
>
> You're welcome.
>  
>
>
>     Actually, I'm using the 0.8.
>
>
> LOL.  Wow, you really like to live at the cutting edge.  No, that's
> not just cutting, that's bleeding (as in gushing blood!) :-)  Fabian's
> been checking in changes today, Jonathan checked in more changes since
> you posted.  It's still actively being developed.  As to your crash...
> uh... how about we wait until the code is stable before debugging
> that. :-)
Correct, I have just implemented the last missing features in the 0.8
table. I am now moving into the bug fixing and documentation phase and I
expect to have still some work to do. I guess this is the fastest
adoption of a widget ever :-) From now on I am open for bug reports on
the 0.8 table. It really is a one to one port of the 0.7 table with its
complete API and all of its bugs.

>  
>
>     But I've asked about the cell editor because even in the
>     qx.ui.table.model.Remote
>     <http://demo.qooxdoo.org/current/apiviewer/#qx.ui.table.model.Remote>
>     0.7.3 API, there aren't those method used in the example here
>     <http://localhost:666/playpen/qxoodoo-0.8-alpha2-pre-sdk/qooxdoo/frontend/application/demobrowser/source/index.html#table%7ETable_Cell_Editor.html>.
>
>
> That's correct.  The example you reference does not use a Remote data
> model.  If you look at line 187, it's creating a new
> qx.ui.table.model.Simple.  But like I said, the cell editors are not
> specific to a data model.  The model's setValue() method gets called
> by the table code when you close a cell editor.  If you look at
> Remote.js, you'll see that its setValue() method fires an
> EVENT_TYPE_DATA_CHANGED event.  Your subclass of Remote would
> presumably catch that event and send the changed data up to your
> backend.  In the Simple model, the value is simply saved locally.
>
>
>     And all examples here
>     <http://demo.qooxdoo.org/current/demobrowser/#example%7ETable_1.html>
>     show table using Simple model. Where can I find other examples?
>     including examples of progressive's widgets.
>
>
> AFAIK, there are currently no examples of using the Remote model.  The
> problem is that there is no backend running on the qooxdoo site, so
> there's nothing for it to talk to.  I thought I had seen an example of
> a Remote model that actually talked to itself to demonstrate how to
> implement the required methods, but I can't find that now.
As Derrell said there is no server backend installed on qooxdoo.org. For
this reason we have no demos for the remote table model. Derrell, how
hard would it be to put a simple PHP file on the server, which serves as
data provider for a Remote table model demo? Maybe we could do the same
for the RPC stuff. This is now open for a long time but I don't know PHP
enough to do it myself.

>
> As to Progressive, the demos have not made it to the web site for some
> reason.  If you check out the legacy_0_7 branch, though, you'll find  
> these in demobrowser:
>
> example/ProgressiveLoader_1.html
> example/ProgressiveTable_1.html
> example/ProgressiveTable_2.html
> example/ProgressiveTable_3.html
> example/ProgressiveTable_4.html
> example/ProgressiveTable_5.html
> example/ProgressiveTable_6.html
The last demo upload for the legacy branch was before you checked in the
progressive demos. I'll see if I can update the online legacy demos.




> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: [0.8] Tables

Fabian Jakobs
Administrator
Fabian Jakobs schrieb:

> Good morning ererybody,
>
>  
>> On Tue, Jul 29, 2008 at 5:12 PM, Guilherme Aiolfi <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     What a great explanation. Thank you for that.
>>
>>
>> You're welcome.
>>  
>>
>>
>>     Actually, I'm using the 0.8.
>>
>>
>> LOL.  Wow, you really like to live at the cutting edge.  No, that's
>> not just cutting, that's bleeding (as in gushing blood!) :-)  Fabian's
>> been checking in changes today, Jonathan checked in more changes since
>> you posted.  It's still actively being developed.  As to your crash...
>> uh... how about we wait until the code is stable before debugging
>> that. :-)
>>    
> Correct, I have just implemented the last missing features in the 0.8
> table. I am now moving into the bug fixing and documentation phase and I
> expect to have still some work to do. I guess this is the fastest
> adoption of a widget ever :-) From now on I am open for bug reports on
> the 0.8 table. It really is a one to one port of the 0.7 table with its
> complete API and all of its bugs.
>
>  
>>  
>>
>>     But I've asked about the cell editor because even in the
>>     qx.ui.table.model.Remote
>>     <http://demo.qooxdoo.org/current/apiviewer/#qx.ui.table.model.Remote>
>>     0.7.3 API, there aren't those method used in the example here
>>     <http://localhost:666/playpen/qxoodoo-0.8-alpha2-pre-sdk/qooxdoo/frontend/application/demobrowser/source/index.html#table%7ETable_Cell_Editor.html>.
>>
>>
>> That's correct.  The example you reference does not use a Remote data
>> model.  If you look at line 187, it's creating a new
>> qx.ui.table.model.Simple.  But like I said, the cell editors are not
>> specific to a data model.  The model's setValue() method gets called
>> by the table code when you close a cell editor.  If you look at
>> Remote.js, you'll see that its setValue() method fires an
>> EVENT_TYPE_DATA_CHANGED event.  Your subclass of Remote would
>> presumably catch that event and send the changed data up to your
>> backend.  In the Simple model, the value is simply saved locally.
>>
>>
>>     And all examples here
>>     <http://demo.qooxdoo.org/current/demobrowser/#example%7ETable_1.html>
>>     show table using Simple model. Where can I find other examples?
>>     including examples of progressive's widgets.
>>
>>
>> AFAIK, there are currently no examples of using the Remote model.  The
>> problem is that there is no backend running on the qooxdoo site, so
>> there's nothing for it to talk to.  I thought I had seen an example of
>> a Remote model that actually talked to itself to demonstrate how to
>> implement the required methods, but I can't find that now.
>>    
> As Derrell said there is no server backend installed on qooxdoo.org. For
> this reason we have no demos for the remote table model. Derrell, how
> hard would it be to put a simple PHP file on the server, which serves as
> data provider for a Remote table model demo? Maybe we could do the same
> for the RPC stuff. This is now open for a long time but I don't know PHP
> enough to do it myself.
>
>  
>> As to Progressive, the demos have not made it to the web site for some
>> reason.  If you check out the legacy_0_7 branch, though, you'll find  
>> these in demobrowser:
>>
>> example/ProgressiveLoader_1.html
>> example/ProgressiveTable_1.html
>> example/ProgressiveTable_2.html
>> example/ProgressiveTable_3.html
>> example/ProgressiveTable_4.html
>> example/ProgressiveTable_5.html
>> example/ProgressiveTable_6.html
>>    
> The last demo upload for the legacy branch was before you checked in the
> progressive demos. I'll see if I can update the online legacy demos.
>  
It is online but there are no links on the demo page. You can find them
on this URL <http://demo.qooxdoo.org/0.7.4-pre/demobrowser/>.

Best Fabian


--
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: [0.8] Tables

thron7
In reply to this post by Petr Kobalíček
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 <[hidden email]>:
>  
>> On Tue, Jul 29, 2008 at 3:52 PM, Guilherme Aiolfi <[hidden email]> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: [0.8] Tables

Krycek
> 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 <[hidden email]>
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 <[hidden email]>:
>
>> On Tue, Jul 29, 2008 at 3:52 PM, Guilherme Aiolfi <[hidden email]> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: [0.8] Tables

Fabian Jakobs
Administrator
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 <[hidden email]
> <mailto:[hidden email]>>
>
>     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 <[hidden email]
>     <mailto:[hidden email]>>:
>     >
>     >> On Tue, Jul 29, 2008 at 3:52 PM, Guilherme Aiolfi
>     <[hidden email] <mailto:[hidden email]>> 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
>     >> [hidden email]
>     <mailto:[hidden email]>
>     >> 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
>     > [hidden email]
>     <mailto:[hidden email]>
>     > 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
>     [hidden email]
>     <mailto:[hidden email]>
>     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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: [0.8] Tables

Derrell Lipman
In reply to this post by Fabian Jakobs
On Wed, Jul 30, 2008 at 2:25 AM, Fabian Jakobs <[hidden email]> wrote:
Derrell, how
hard would it be to put a simple PHP file on the server, which serves as
data provider for a Remote table model demo? Maybe we could do the same
for the RPC stuff. This is now open for a long time but I don't know PHP
enough to do it myself.

That'd be easy to do if the server has PHP installed (hopefully PHP5, but not absolutely mandatory).  If you send me login info, I could get that set up some time this week I think.
 
>
> As to Progressive, the demos have not made it to the web site for some
> reason.  If you check out the legacy_0_7 branch, though, you'll find
> these in demobrowser:
>
> example/ProgressiveLoader_1.html
> example/ProgressiveTable_1.html
> example/ProgressiveTable_2.html
> example/ProgressiveTable_3.html
> example/ProgressiveTable_4.html
> example/ProgressiveTable_5.html
> example/ProgressiveTable_6.html
The last demo upload for the legacy branch was before you checked in the
progressive demos. I'll see if I can update the online legacy demos.

Great.  Thanks.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: [0.8] Tables

Fabian Jakobs
Administrator
Derrell Lipman schrieb:

> On Wed, Jul 30, 2008 at 2:25 AM, Fabian Jakobs <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Derrell, how
>     hard would it be to put a simple PHP file on the server, which
>     serves as
>     data provider for a Remote table model demo? Maybe we could do the
>     same
>     for the RPC stuff. This is now open for a long time but I don't
>     know PHP
>     enough to do it myself.
>
>
> That'd be easy to do if the server has PHP installed (hopefully PHP5,
> but not absolutely mandatory).  If you send me login info, I could get
> that set up some time this week I think.
>  
That won't be necessary and I guess I won't be allowed to do so. We can
place the PHP files in the demobrowser's resource directory and copy
them to the server using our normal "publish" process. The advantage is
that everybody can test it with the download version by simply putting
the qooxdoo frontend directory on a PHP enabled server. I have prepared
the skeleton for a remote table model demo in trunk:

Client:
frontend/application/demobrowser/source/demo/table/Table_Remote_Model.html
Server:
frontend/application/demobrowser/source/resource/demobrowser/backend/remote_table.php

It would be fantastic if we could get a table with a remote model into
the demos.


Best Fabian

--
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: [0.8] Tables

Krycek
In reply to this post by Derrell Lipman
> 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 <[hidden email]>
On Tue, Jul 29, 2008 at 3:52 PM, Guilherme Aiolfi <[hidden email]> 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

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: [0.8] Tables

Derrell Lipman


On Thu, Jul 31, 2008 at 3:20 PM, Guilherme Aiolfi <[hidden email]> wrote:
> 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?

Ah, sorry, you're missing the mixin.  I don't believe I ever received any confirmation from anyone way-back-when that this works and I haven't tested it.  That's why I never checked it in.  You'll see that this patch modifies Simple to use the provided mixin and you'll have to do similarly with Remote:

  qx.Class.patch(qx.ui.table.model.Remote, qx.ui.table.model.MEditable);

I don't recall the details of why this couldn't just be added to Abstract but there was something with breaking backward compatibility.

Please let me know how this patch works for you.

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

x.patch (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [0.8] Tables

Krycek
Hey Derrell,

It worked. I believe you want to know if it worked in the 0.7.3. Well, I've applied this patch to 0.8, but should work in the 0.7.3 as well, right?

Shouldn't it be in the 0.8 from now on?

Thank you!

Guilherme

2008/7/31 Derrell Lipman <[hidden email]>


On Thu, Jul 31, 2008 at 3:20 PM, Guilherme Aiolfi <[hidden email]> wrote:
> 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?

Ah, sorry, you're missing the mixin.  I don't believe I ever received any confirmation from anyone way-back-when that this works and I haven't tested it.  That's why I never checked it in.  You'll see that this patch modifies Simple to use the provided mixin and you'll have to do similarly with Remote:

  qx.Class.patch(qx.ui.table.model.Remote, qx.ui.table.model.MEditable);

I don't recall the details of why this couldn't just be added to Abstract but there was something with breaking backward compatibility.

Please let me know how this patch works for you.

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: [0.8] Tables

Derrell Lipman
On Thu, Jul 31, 2008 at 4:41 PM, Guilherme Aiolfi <[hidden email]> wrote:
Hey Derrell,

It worked. I believe you want to know if it worked in the 0.7.3. Well, I've applied this patch to 0.8, but should work in the 0.7.3 as well, right?

Well the patch probably applied cleanly, but I expect it doesn't work correctly in 0.8 because the patch uses createDispatchEvent() instead of the new-in-0.8  fireEvent().
 
Shouldn't it be in the 0.8 from now on?

Yes it should.  I've applied that set of methods directly to Remote.js.  No need for the mixin in 0.8.

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