[Toaster] [review-request] 5933 "link for the task order misses if anchor not in first page"

[Damian, Alexandru]

David, your patch is taken.

Alex


On Mon, Mar 31, 2014 at 11:38 AM, Barros Pena, Belen <
belen.barros.pena at intel.com> wrote:

> On 29/03/2014 15:06, "Reyna, David" <david.reyna at windriver.com> wrote:
>
> >Hi Belen,
> >
> >I have the task anchors page to the proper All Tasks page working.
> >
> >The commit branch is: dreyna/task_anchor_5933
>
> I have tested this with my patches for the blue highlight animation:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=bbarrosp/f
> ront-end&id=0b469d5c5a047a18cb255c07c254a3e71d4353b9
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=bbarrosp/f
> ront-end&id=ec0a03abbad9fd964b1f438471515e4a98a74a72
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=bbarrosp/f
> ix-6033&id=71c43cf4e07fe4ad353be3afb0dec21bd73e5d66
>
>
> And from the UI standpoint this is working pretty well.
>
> Cheers
>
> Belén
>
>
>
> >
> >The implementation was tricky. Here are my notes, which I will add to
> >bugzilla to track for the future:
> >
> >  * Since the ³#² anchor is never passed to the server, I updated the
> >link to also include the anchor in the normal part of the URL so that it
> >could be passed to the view class.
> >
> >  * I updated ³urls.py² to catch that new URL, and the view class now
> >gets this new optional anchor value.
> >
> >  * The view class will immediately do a redirect since the mandatory
> >parameters will not be present. I allow this so that we can drop the URL
> >extension and not be caught in a locked loop. I instead move the anchor
> >value to a parameter (³anchor²).
> >
> >
> >While using a parameter may appear to be much the same thing and using
> >part of the base URL, it is in practice very different. URLs are
> >immutable, but parameters can be made mutable (with a copy/replace on the
> >GET array), and thus I can escape that lock
> > once I sort the pages.
> >
> >  * Once the queryset is set up and before the pagination, the code
> >iterates through the queryset until it finds its anchor value. It then
> >computes the new page, updates the page number, drops the anchor
> >parameter, and does a redirect. Everything is now
> > back to normal workflow.
> >
> >I did experiment with not doing the last redirect and avoiding the
> >duplicate query. The problem is that the resulting URL in the browser
> >will always refer to page 1 even though the proper page is displayed, and
> >while this does not affect the functionality
> > I am concerned it will cause problems later. Also, for some reason
> >without the redirect by browser will not let go of the ³#² anchor. Again
> >this does not affect the functionality but it looks wrong and could have
> >consequences later, especially since Javascript
> > code would see this incorrect URL and could break in odd ways.
> >
> >- David
> >
> >
>
>


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