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#Annotations > > > > > > 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
