Turbogears2 migration: paging failures in changelog

[Thomas De Schampheleire]

On Tue, Jul 12, 2016 at 12:55 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
> On 06/30/2016 08:11 PM, Thomas De Schampheleire wrote:
>
> Hi Alessandro, all,
>
> With the current state of the kallithea-tg repo, the test suite looks
> quite good. There is a large number of failures due to a single root
> cause: the PUT/DELETE requests not being allowed. I hope Søren can
> have a look at that, after which many tests will succeed.
>
> I'm now looking at the other tests. One specific failure is easy to
> reproduce, either:
>
> $ py.test kallithea/tests/functional/test_changelog.py
>
> or interactively by launching kallithea with the test.ini:
>
> $ paster serve kallithea/tests/test.ini
> then browsing to one of either repos vce_test_hg/git and then to
> 'Changelog'.
>
> This renders a 500 Server Error without traceback or further information.
> I was able to zoom in on the problem with manual traces, and found it
> is related to pagination. If I remove the pagination block from the
> template (see patch below) then the Changelog page works fine (except
> for pagination, of course).
>
> diff --git a/kallithea/templates/changelog/changelog.html
> b/kallithea/templates/changelog/changelog.html
> --- a/kallithea/templates/changelog/changelog.html
> +++ b/kallithea/templates/changelog/changelog.html
> @@ -160,7 +160,6 @@
>                   </div>
>
>                   <div class="pagination-wh pagination-left">
> -                    ${c.pagination.pager('$link_previous ~2~ $link_next')}
>                   </div>
>               </div>
>           </div>
>
>
> However, it is unclear to me how to proceed. What is the problem with
> this pagination, why is it a problem under Turbogears2 and not under
> Pylons? How to see more details about the failures?
>
>
> Pagination seems odd to me - especially in the current implementation.
>
> It kind of would make sense to have "page with users with names starting
> with L-P" or "changesets made 2-5 weeks ago" ... but labeling a page number
> 6 and showing item 300 to 350 doesn't make much sense. Especially because we
> usually pass all the data to the template anyway - sometimes even to the
> client side.
>
> Something like the eternal scrolling on https://selenic.com/hg/shortlog/
> would perhaps be a better solution (except the exponential "page"
> navigation).
>
> I'm not sure we actually _need_ "pagination" in other places than the
> changelog. And perhaps when listing closed PRs. And notifications and
> "journal".

I see two separate items:
* improve paging in Kallithea
* convert from Pylons to Turbogears2

I think that the migration to Turbogears2 should result in the same
behavior as under Pylons, and that even means a working but possibly
non-logical paging behavior. If the paging improvements you envision
were a quick-fix, we could consider doing them first and then
continuing the migration to Turbogears2 on top of that, but I think
they are not. Even then, is there any guarantee that the 'new' paging
would not be a problem under Turbogears2 as I encounter?

I think that I am missing some debugging skills in python - Kallithea
- mako - Turbogears2. I would be grateful if others with more
experience could help me on that. In this problem, it looks like there
is some kind of template rendering problem, but without any hint in
the logs.

Thanks,
Thomas