[Toaster] V2 [review-request] 6040, 7249, and 7461: daterange filtering for builds page, filter counts

[Damian, Alexandru]

Taken as noted on the other mail thread.

Alex

On Sun, Mar 22, 2015 at 1:59 AM, Reyna, David <david.reyna at windriver.com>
wrote:

>  Hi Michael and Belén,
>
> I have created a V2 of the date range patch to address Michael’s
> recommendations:
>
> 1) This patch includes 7461 “Filters not working as designed”
>
> I hid the filter counts and turned off the button disables. I did keep the
> backend code around so that we reuse/adapt it later.
>
> 2) The javascript from “filtersnippet.html” has been moved to
> “/static/js/filtersnippet.js"
>
> To compensate I have added context values (to pass the values) and
> “data-*” attributes (to hold the data with the respective controls). The
> latter is needed because “datepicker” loses all its settings when its input
> box is disabled, so I have to be able to restore the state on the fly.
>
> A side benefit is that I was able to remove almost all of the added
> unnamed tuple variables. I left just one so that I did not have to re-write
> Belén dense hover pop-up that allows one to switch the filter back to “Show
> All”, but we are otherwise no worse than Toast-1.7.
>
> FYI, I found I had to use DOM to fetch some elements in these routines,
> because jQuery just could not find those same elements.
>
> 3) There is no longer a page redirect to validate/reconstitute the dynamic
> date range filter
>
> To compensation I have added a routine to catch and modify the
> filter_string after it is fetched but before it is used, plus I added some
> more context variables.
>
> FYI, I spent a lot of time trying to do the whole validation and reparsing
> of the date range filter string in the javascript before it is returned to
> the view classes, but I finally gave up when I discovered that the date()
> support in javascript does not support date addition. This feature is
> needed because the “to” date is expected to include that date, and that in
> turn means it must be incremented to the beginning of the next day before
> being used. (I could have played with fetching the object’s UNIX time
> integer, adding a day’s worth of seconds, and making a new Date object, but
> that looked ugly and un-safe).
>
> 4) Various other style improvements
>
> I have tested it in managed and interactive mode, using valid and
> empty/in-valid dates (which are caught and forced to ‘today’).
>
> The only usage oddity is that if you do use Belén hover pop-up to switch
> the filter back to “Show All”, the date range pickers lose their previous
> values (since they are passed in the URL), but that is a small thing and
> the values are easily re-entered. We can fix that when we update our
> persistence model in YP-1.9.
>
> - David
>
>
>



-- 
Alex Damian
Yocto Project
SSG / OTC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/toaster/attachments/20150324/a9e9a38c/attachment.html>