Re: [xwiki-devs] [Proposal] Support choosing pagination size in livetable UI
----- "Denis Gervalle" <[email protected]> wrote:
On Thu, May 6, 2010 at 15:43, Jerome Velociter <[email protected]> wrote:
Hi Denis,
It's pretty nice.
I've added an annotation on the patch
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/LivetablePageSizer#...
The annotation dropped the end of my selection, it actually concerns
the
following lines :
+ #if($!hasPageSize) + document.observe("xwiki:livetable:${divid}:loadingEntries", function() { $('${divid}-pagesize').addClassName("hidden"); } ); + document.observe("xwiki:livetable:${divid}:loadingComplete", function() { $('${divid}-pagesize').removeClassName("hidden"); } ); + #end
Well, I do not follow. The JS is able to display one or more control, anywhere you want.
As well as it could be able to do the hiding on all such controls (LiveTablePageSizer has a references on all said domNodes) Choosing to put only one, and in the same place
then the loading bar is just a design choice, that is the responsability of the code that produce the markup (the macro here). And the behavior of hiding the control is related.
I don't see why placing it somewhere else (or having more) you would want a different behavior. In my opinion the macro should just consume the livetable JS constructor. If you need more JS code, it's probably that you need new options in the constructor (options which possibly be callback functions, not necessarly just flags/values). Finally, I think the proper behavior here would be to disable the control, instead of hidding its container. WDYT? Jerome. This is why I choose to add a additional even to
the table, and put the observe in the macro.
Denis
Jerome.
----- Original Message ----- From: "Guillaume Lerouge" <[email protected]> To: "XWiki Developers" <[email protected]> Sent: Thursday, May 6, 2010 3:10:01 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [xwiki-devs] [Proposal] Support choosing pagination size in livetable UI
Hi,
On Thu, May 6, 2010 at 15:05, Denis Gervalle <[email protected]> wrote:
On Thu, May 6, 2010 at 14:55, Guillaume Lerouge <[email protected]> wrote:
Hi,
On Thu, May 6, 2010 at 14:33, Denis Gervalle <[email protected]> wrote:
Hi devs,
Currently the number of rows displayed in a livetable is fixed at creation time. I proposed to add UI controls (currently select) that allows to change the pagination size freely by the end user.
This patch is be both a change in livetable.js to support these controls (one or more), and a change in the livetable macro to allow displaying them. I have already a patch and some screenshots as well as bare documentation, you can review them all at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/LivetablePageSizer
I am currently testing different browsers to ensure there is
no regression.
WDYT ?
Sounds very nice to me, I was asked about it in the past so I'm +1.
Only question -> is the preference remembered for the user? I guess not and that the default still is the number chose by the livetable creator, but thought I'd ask.
Well this is mainly a new functionality on the livetable, no change in XE in my patch currently. My feeling is that keeping the information for the user should not be done by the livetable itself (JS), but by the caller (the macro, why not). It would not be so difficult to do with cookies, it would be a little bit more work to store the information in the user profile. Anyway, this is a second step.
By the way, I have not proposed to change the current pages of XE, but it could be a nice idea. Do not hesitate to propose page you want me to improve. The other way, we may also set this new feature as a default, so it will apear on all existing livetables using the macro, and allow disabling it. WDYT ?
Yes, I'd make this available by default to all livetables, with a configuration parameter allowing to disable it on a case-by-case basis.
Guillaume
Denis
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Thu, May 6, 2010 at 17:03, Jerome Velociter <[email protected]> wrote:
----- "Denis Gervalle" <[email protected]> wrote:
On Thu, May 6, 2010 at 15:43, Jerome Velociter <[email protected]> wrote:
Hi Denis,
It's pretty nice.
I've added an annotation on the patch
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/LivetablePageSizer#...
The annotation dropped the end of my selection, it actually concerns
the
following lines :
+ #if($!hasPageSize) + document.observe("xwiki:livetable:${divid}:loadingEntries", function() { $('${divid}-pagesize').addClassName("hidden"); } ); + document.observe("xwiki:livetable:${divid}:loadingComplete", function() { $('${divid}-pagesize').removeClassName("hidden"); } ); + #end
Well, I do not follow. The JS is able to display one or more control, anywhere you want.
As well as it could be able to do the hiding on all such controls (LiveTablePageSizer has a references on all said domNodes)
Choosing to put only one, and in the same place
then the loading bar is just a design choice, that is the responsability of the code that produce the markup (the macro here). And the behavior of hiding the control is related.
I don't see why placing it somewhere else (or having more) you would want a different behavior.
In my opinion the macro should just consume the livetable JS constructor. If you need more JS code, it's probably that you need new options in the constructor (options which possibly be callback functions, not necessarly just flags/values).
Finally, I think the proper behavior here would be to disable the control, instead of hidding its container.
WDYT?
I am not sure you get the idea. Here I am hiding the control, so it does not take place while the loading progress bar is shown. All this is just to have something nice in the current design of the livetable. If the control is located elsewhere, there is no requirement to hide it, and I think there is no real side effet, if you change the page size while loading. So this is not here to prohibit you from changing the page size, it is just a question of design. Keeping it, and the loading bar, would be larger than the minimum width of the skin and the pages numbers would have to go on a second line while the loading bar is displayed. Moreover, this look really nice. So for me, this behavior cames with the livetable macro, since the livetable macro is responsible of the current design of the livetable. If another code, not using the livetable macro choose to put the controls in many places, and would like only to hide none or even part of them, it could do so as well. So if I put a feature to hide them all in the livetable.js it will be useless. And to be complete, then, why not put code to hide filters, numbers, etc... Denis
Jerome.
This is why I choose to add a additional even to
the table, and put the observe in the macro.
Denis
Jerome.
----- Original Message ----- From: "Guillaume Lerouge" <[email protected]> To: "XWiki Developers" <[email protected]> Sent: Thursday, May 6, 2010 3:10:01 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [xwiki-devs] [Proposal] Support choosing pagination size in livetable UI
Hi,
On Thu, May 6, 2010 at 15:05, Denis Gervalle <[email protected]> wrote:
On Thu, May 6, 2010 at 14:55, Guillaume Lerouge <[email protected]> wrote:
Hi,
On Thu, May 6, 2010 at 14:33, Denis Gervalle <[email protected]> wrote:
Hi devs,
Currently the number of rows displayed in a livetable is fixed at creation time. I proposed to add UI controls (currently select) that allows to change the pagination size freely by the end user.
This patch is be both a change in livetable.js to support these controls (one or more), and a change in the livetable macro to allow displaying them. I have already a patch and some screenshots as well as bare documentation, you can review them all at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/LivetablePageSizer
I am currently testing different browsers to ensure there is
no regression.
WDYT ?
Sounds very nice to me, I was asked about it in the past so I'm +1.
Only question -> is the preference remembered for the user? I guess not and that the default still is the number chose by the livetable creator, but thought I'd ask.
Well this is mainly a new functionality on the livetable, no change in XE in my patch currently. My feeling is that keeping the information for the user should not be done by the livetable itself (JS), but by the caller (the macro, why not). It would not be so difficult to do with cookies, it would be a little bit more work to store the information in the user profile. Anyway, this is a second step.
By the way, I have not proposed to change the current pages of XE, but it could be a nice idea. Do not hesitate to propose page you want me to improve. The other way, we may also set this new feature as a default, so it will apear on all existing livetables using the macro, and allow disabling it. WDYT ?
Yes, I'd make this available by default to all livetables, with a configuration parameter allowing to disable it on a case-by-case basis.
Guillaume
Denis
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
participants (2)
-
Denis Gervalle -
Jerome Velociter