tgext.routes changes

[Søren Løvborg]

Sorry for the delay, I've been deep in the Alembic stuff (supporting
migrations across three database engines is hard). :-)

There are a number of ways to proceed:

1) "The status quo hack"

Hack the TG port to emulate Routes (that is: use _method for routing, but
don't actually change HTTP request method), or hack Kallithea to reset
request method to POST after the routing step. Example:

https://bitbucket.org/Unity-Technologies/kallithea/commits/714021984b5894fa74a88bfaa228fef4b0f545b7

As can be seen, this the quick and dirty solution, and might be viable as a
transitional hack.

2) "Kill _method and change the URLs"

Remove _method overrides completely (and good riddance) by changing
PUT/DELETE routes to POST and adjusting URLs as needed to avoid ambiguity.

https://bitbucket.org/Unity-Technologies/kallithea/commits/0a71c69001b2b54e24a9bc1bc89b2fe0f1ea9898

As can be seen, there's a lot of work down this road; the above changeset
fixes 2 out of 40 PUT/DELETE routes.

This also changes a number of URLs, it might be worthwhile to consider
where we want to go with Kallithea's URLs before embarking on this, since
there are numerous other problems in this area; the Kallithea URLs are
often ambiguous in regards to repository paths, and we really need to fix
that too. (Never name a repository "changelog", or "1", for that matter...)

3) "s/_method/action/"

As an alternative to 2, the URLs could be kept the same, and the PUT/DELETE
controllers could be merged into a unified (possibly existing) POST
controller. The controller would branch based on form data, like an
"action" field (just like "_method", but without the HTTP baggage). This
might be even more work, though.

Best,
Søren


On Wed, Jun 29, 2016 at 9:35 PM, Thomas De Schampheleire <
patrickdepinguin at gmail.com> wrote:

> Hi Søren,
>
> On Tue, May 3, 2016 at 8:25 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
> > On 05/03/2016 03:13 PM, Søren Løvborg wrote:
> >>
> >> Considering that method overrides are designed specifically to
> >> accommodate HTML forms, we could pull the CSRF token out of the POST
> >> request body and stuff it into a header as part of the override
> >> process. But at that point, it just feels like we're digging ourselves
> >> in even deeper. A saner approach would be to phase out method
> >> overrides altogether, and just let POST requests be POST requests.
> >> (Add an "action" argument or similar as needed, but leave that to the
> >> controller, and keep it out of routing and security checks.)
> >
> >
> > It seems like that would be a general refactoring and code improvement
> that
> > could be done on the default branch and pave the way for the TG
> migration?
>
> I was wondering whether you would be up to tackling this in the near
> future? (or perhaps you already started with this?)
>
> Of the current tests that are failing, the majority is failing due to
> the DELETE method not being accepted. I am meanwhile fixing the other
> failures, but it would be great if in a parallel path someone could
> look at the DELETE thing.
>
> You can see the current state of the Turbogears2 migration code to
> https://bitbucket.org/_amol_/kallithea-tg/
> See also:
> https://bitbucket.org/conservancy/kallithea/wiki/Turbogears2Migration
>
> Do let me know your thoughts...
>
> Best regards,
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20160707/328cdaad/attachment.html>