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

[Barros Pena, Belen]

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
> 
>