On 29/03/2014 15:06, "Reyna, David" <[email protected]> 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 > > -- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
