Turbogears2 migration: custom error pages

[Thomas De Schampheleire]

Hi Alessandro,

On Fri, Feb 19, 2016 at 10:14 PM, Thomas De Schampheleire
<patrickdepinguin at gmail.com> wrote:
> On Thu, Feb 18, 2016 at 4:23 PM, Alessandro Molina
> <alessandro.molina at gmail.com> wrote:
>>
>>
>> On Thu, Feb 18, 2016 at 4:13 PM, Thomas De Schampheleire
>> <patrickdepinguin at gmail.com> wrote:
>>>
>>>
>>> So this means that Kallithea would start using the 'default' routing
>>> method used by Turbogears projects?
>>> Is this a big impact / does it require a lot of work, according to you?
>>
>>
>> Nope, just that instead of relying RoutesMiddleware to run mapper.routematch
>> and fill environ with routes variables (routes.url, routes.route,
>> wsgiorg.routing_args) those should be filled by RootController itself.
>>
>> Actually as I'm moving the routing logic from Kallithea to tgext.routes (so
>> that Kallithea can just use it instead of implementing custom routing
>> itself) that change is already undergoing, but I didn't have time to finish
>> it so far.
>>
>>
>
> Thanks, that sounds good...
>
> Meanwhile I can confirm that my scenario with custom error pages work fine now.
>

Found a case where the custom error pages do not work, e.g. with this change:

diff --git a/kallithea/controllers/home.py b/kallithea/controllers/home.py
--- a/kallithea/controllers/home.py
+++ b/kallithea/controllers/home.py
@@ -67,6 +67,7 @@ class HomeController(BaseController):
         #json used to render the grid
         c.data = json.dumps(repos_data)

+        raise HTTPBadRequest()
         return render('/index.html')

     @LoginRequired()


and loading the home page, causes a plain page with text
"400 Bad Request
The server could not comply with the request since it is either
malformed or otherwise incorrect."

I verified that the same change on original Kallithea has the custom
error page correctly displayed...

Ideas?



Meanwhile, the pytest migration has finished. I am planning to
rebasing our current codebase on the latest Kallithea upstream to
avoid making changes on obsolete code. Especially since I'm seeing
many test failures with Turbogears2, and I expect that at least in
some cases the test themselves should be fixed.
This rebase could also incur some squashing of patches, to make it
more ready for upstreaming. What do you think of that? And shall I
push the result to your bitbucket repo or rather to another one?

Thanks,
Thomas