On Wed, Apr 21, 2010 at 12:35, Jerome Velociter <[email protected]> wrote:
> Hello Denis,
>
> > Hi devs,
> >
> > We have a customer request for highlighting the filters that are
> currently
> > applied on a livetable. The rationale of this, is that sometimes the
> > filtered table is empty or unexpected by the user, but he does not notice
> > that a filter is currently applied. We have written a proposed
> > implementation as well and you may also see what it looks like in the
> > attached screenshot, for both text field and select box (for webkit).
> >
> > Currently, I choose yto use the "background highlight color" of the
> active
> > color theme, but my feeling is that adding another highlight color would
> > be
> > better.
>
> I agree
Well, since I have not followed what have been discuss regarding the color
theme, what would be the process to add a new color in it ? How do we expect
to manage the evolution of the color theme to avoid it to became cluttered ?
Should we open a discussion on that if none have been already ?
> >
> > I have also hook to events separately from the "main" refresh handler,
> > because I do not understand the implementation of this handler. Why using
> > an
> > intermediate makeRefreshHandler, and why it does not properly provide the
> > currently changed filter to the handler ? Could or should I change that ?
>
> Yes you can. The refresh handler should probably not return a function but
> be a livetable function that is bound as event listener, i.e :
>
> this.handleRefresh.bindAsEventListener(this)
>
> versus the current
>
> this.makeRefreshHandler(this)
>
> This way you will be able to access the event from the handler, thus the
> filter that triggered it.
>
Ok, I will adapt my implementation and the current code.
> One last thing : you should not need the try {} catch {} statements in
> your code. I don't see where it could fail (and if it could, I think it's
> better to try to fix it so that it does not happen). Try catch blocks IMO
> should be used only in very specific occasions (for example when you know
> code can fail under certain circumstances, but you don't want to stop the
> execution). Anyway that's just my opinion, we've never stated on this as a
> best practice, but we can discuss it in another thread if needed. I'd be
> curious to get input from Sergiu about this for example.
>
I agree. My habits was that minor JS function (those that do not impact
usability) should never ever crash, so I usually protect them with try/catch
in all cases. This is maybe overkill here. Should we also open a discusion
on this best practice ? Sergiu ?
Denis
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
