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 < patrickdeping...@gmail.com> wrote: > Hi Søren, > > On Tue, May 3, 2016 at 8:25 PM, Mads Kiilerich <m...@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 >
_______________________________________________ kallithea-general mailing list kallithea-general@sfconservancy.org http://lists.sfconservancy.org/mailman/listinfo/kallithea-general