Pooling tables

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

Pooling tables

Jim Hunter
Has anyone tried to create a pool class for tables? It was pretty straight forward for other classes, but the table is not easy to re-use. The table model, if I remember correctly, can't easily be changed on the fly. I am trying to pool all the controls I use so that I get better performance in IE and I do use tables on almost every screen I create. And since they use up a bunch of resources, I was hoping to be able to pool them and save some resources.

Any suggestions would be great.

Thanks,
Jim


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Pooling tables

Derrell Lipman
On Fri, Jul 11, 2008 at 1:46 PM, Jim Hunter <[hidden email]> wrote:
Has anyone tried to create a pool class for tables? It was pretty straight forward for other classes, but the table is not easy to re-use. The table model, if I remember correctly, can't easily be changed on the fly. I am trying to pool all the controls I use so that I get better performance in IE and I do use tables on almost every screen I create. And since they use up a bunch of resources, I was hoping to be able to pool them and save some resources.

Hi Jim,

You're right that some characteristics of tables can't be easily changed on the fly.  It's the table column model (not the table model) that can only be set once.  I looked into this a while back and discovered that there are numerous entanglements in the code that make it very difficult to change it.

That may be the only issue that prevents pooling table instances, so maybe you can pool instances of tables with a separate pool per table/table column model tuple.

Derrell


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Pooling tables

Jim Hunter
Yes, it was the table column model that I was thinking about, not the table model, thanks for correcting me.
So you are thinking that if I have a pool for the column models and a pool for the tables, and for each re-use of the table I just re-associate the model with the table it 'should' work? Then I will give that a try. I have quite a few classes to pour through in the next week before I get to the table class (saving it for last), but I will give that a try.

Thanks Derrell,

Jim


On Fri, Jul 11, 2008 at 10:52 AM, Derrell Lipman <[hidden email]> wrote:
On Fri, Jul 11, 2008 at 1:46 PM, Jim Hunter <[hidden email]> wrote:
Has anyone tried to create a pool class for tables? It was pretty straight forward for other classes, but the table is not easy to re-use. The table model, if I remember correctly, can't easily be changed on the fly. I am trying to pool all the controls I use so that I get better performance in IE and I do use tables on almost every screen I create. And since they use up a bunch of resources, I was hoping to be able to pool them and save some resources.

Hi Jim,

You're right that some characteristics of tables can't be easily changed on the fly.  It's the table column model (not the table model) that can only be set once.  I looked into this a while back and discovered that there are numerous entanglements in the code that make it very difficult to change it.

That may be the only issue that prevents pooling table instances, so maybe you can pool instances of tables with a separate pool per table/table column model tuple.

Derrell


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel




--
Jim Hunter

DAILY THOUGHT: SOME PEOPLE ARE LIKE SLINKIES - NOT REALLY GOOD
FOR ANYTHING BUT THEY BRING A SMILE TO YOUR FACE WHEN PUSHED DOWN THE STAIRS
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Pooling tables

Derrell Lipman
On Fri, Jul 11, 2008 at 1:56 PM, Jim Hunter <[hidden email]> wrote:
So you are thinking that if I have a pool for the column models and a pool for the tables, and for each re-use of the table I just re-associate the model with the table it 'should' work?

Not quite.  Once you associate a table column model with a table, you can't change it.  Therefore you just need to keep track of the column model that's ALREADY been associated with a particular table, and when you're pulling from the pull from the pool, pull a table that was previously associated with the table column model that you now want to use.

Derrell


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Pooling tables

Jim Hunter
But are you able to change the column models properties? I would need to have it associate with a new set of columns for the new use. I thought that was not possible. I never know from one instance of a table to the next what column information it will need.

Jim

On Fri, Jul 11, 2008 at 11:02 AM, Derrell Lipman <[hidden email]> wrote:
On Fri, Jul 11, 2008 at 1:56 PM, Jim Hunter <[hidden email]> wrote:
So you are thinking that if I have a pool for the column models and a pool for the tables, and for each re-use of the table I just re-associate the model with the table it 'should' work?

Not quite.  Once you associate a table column model with a table, you can't change it.  Therefore you just need to keep track of the column model that's ALREADY been associated with a particular table, and when you're pulling from the pull from the pool, pull a table that was previously associated with the table column model that you now want to use.

Derrell


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel




--
Jim Hunter

DAILY THOUGHT: SOME PEOPLE ARE LIKE SLINKIES - NOT REALLY GOOD
FOR ANYTHING BUT THEY BRING A SMILE TO YOUR FACE WHEN PUSHED DOWN THE STAIRS
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Pooling tables

Derrell Lipman
On Fri, Jul 11, 2008 at 2:13 PM, Jim Hunter <[hidden email]> wrote:
But are you able to change the column models properties? I would need to have it associate with a new set of columns for the new use. I thought that was not possible. I never know from one instance of a table to the next what column information it will need.

Looking at the code, it seems that you'd not be able to change the *number* of columns, but could change the attributes of existing columns (e.g. their width).  If your user interface doesn't make the column visibility menu available to your users, I suppose you could create a column model with whatever maximum number of columns you might ever need and then make the unused columns invisible as you prepare to use an instance of the table pulled from the pool.

Derrell


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Pooling tables

Jim Hunter
For my app this is not feasible as I have no idea what the max number of columns used would be, it's all user defined. I would logically think that no more then 50 would be used but I recently saw an instance that had over 100 columns. So I am not sure if it would be practical to create all column models with something like 150 columns. That might use up more memory then I am trying to save.

I suppose I could pool everything but the tables, then hope that the .8 version tables might lend themselves to pooling a little better.

Thanks for your input.

Jim


On Fri, Jul 11, 2008 at 11:19 AM, Derrell Lipman <[hidden email]> wrote:
On Fri, Jul 11, 2008 at 2:13 PM, Jim Hunter <[hidden email]> wrote:
But are you able to change the column models properties? I would need to have it associate with a new set of columns for the new use. I thought that was not possible. I never know from one instance of a table to the next what column information it will need.

Looking at the code, it seems that you'd not be able to change the *number* of columns, but could change the attributes of existing columns (e.g. their width).  If your user interface doesn't make the column visibility menu available to your users, I suppose you could create a column model with whatever maximum number of columns you might ever need and then make the unused columns invisible as you prepare to use an instance of the table pulled from the pool.

Derrell


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel




--
Jim Hunter

DAILY THOUGHT: SOME PEOPLE ARE LIKE SLINKIES - NOT REALLY GOOD
FOR ANYTHING BUT THEY BRING A SMILE TO YOUR FACE WHEN PUSHED DOWN THE STAIRS
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Pooling tables

Fabian Jakobs
Administrator
Hi Jim,

> For my app this is not feasible as I have no idea what the max number
> of columns used would be, it's all user defined. I would logically
> think that no more then 50 would be used but I recently saw an
> instance that had over 100 columns. So I am not sure if it would be
> practical to create all column models with something like 150 columns.
> That might use up more memory then I am trying to save.
>
> I suppose I could pool everything but the tables, then hope that the
> .8 version tables might lend themselves to pooling a little better.

I'm sorry but I have to dissapoint you in this regard :-( The table of
0.8 will be a port of the 0.7 table. We plan to rework many aspects of
the table but only after 0.8. It would simply blow our release schedule.
Maybe we could start collecting requirements to the "new" table. Being
able to pool tables would be one of those requirements.

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


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Pooling tables

Jim Hunter
Well, then I guess I will have to wait for it. I have an idea for pooling the tables, I'll post it if I get it working.

Jim


On Mon, Jul 14, 2008 at 12:35 AM, Fabian Jakobs <[hidden email]> wrote:
Hi Jim,

> For my app this is not feasible as I have no idea what the max number
> of columns used would be, it's all user defined. I would logically
> think that no more then 50 would be used but I recently saw an
> instance that had over 100 columns. So I am not sure if it would be
> practical to create all column models with something like 150 columns.
> That might use up more memory then I am trying to save.
>
> I suppose I could pool everything but the tables, then hope that the
> .8 version tables might lend themselves to pooling a little better.

I'm sorry but I have to dissapoint you in this regard :-( The table of
0.8 will be a port of the 0.7 table. We plan to rework many aspects of
the table but only after 0.8. It would simply blow our release schedule.
Maybe we could start collecting requirements to the "new" table. Being
able to pool tables would be one of those requirements.

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


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel



--
Jim Hunter

DAILY THOUGHT: SOME PEOPLE ARE LIKE SLINKIES - NOT REALLY GOOD
FOR ANYTHING BUT THEY BRING A SMILE TO YOUR FACE WHEN PUSHED DOWN THE STAIRS
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel