Turbogears2 migration: API calls

[Alessandro Molina]

>
> So the routing tries to access an index method.
>
> In the API code, the JSONRPCController parent class of ApiController
> is supposed to direct the calls to the correct method, but it seems we
> do not enter that class.
>
>
JSONRPCController needs to be able to implement his own routing and
tgext.routes had support for mounting a regex routed controller inside an
ObjectDispatch controller but didn't provide support for the opposite
(mounting a subcontroller inside a regex routed controller). So it didn't
support dispatching further from the result of the regex match. (which
ended up in looking for index as it reached the ApiController and not
further).

I managed to get it dispatch to the right method, but still need to write
tests for the tgext.routes changes and check that the whole API tests pass,
so it will probably be a few days before I can push something decent. And
it will surely need review by someone that knew how JSONRPCController
worked as I'll probably miss some expected behaviours.


> I have seen in the TG2 documentation that typical, recommended, usage
> is different than what Kallithea is doing, and I think we should
> investigate if we can adapt our code base to such best practices
> eventually, but in the short term I think we should try to make the
> existing code base work.


There are three major things that Kallithea does that are different from
usual TG apps:

  - Routing, Kallithea is probably the only TG2 app using routes as the
core dispatch system. This is probably not going away unless all
controllers are rewritten using ObjectDispatch. But as using tgext.routes
as the main dispatch system should be possible I tend to think that
Kallithea should not be forced to change this and I can work to fix any
problems that arise.

  - Expositions, currently it calls render explicitly at end of each
controller, but the suggested and preferred way in TurboGears is using
@expose and let TG do the template rendering, caching and template choice
based on content_type. Most should work also by manually calling rendering,
but kallithea might face problems due to this in the future as it is in
fact skipping the whole Decoration/Exposition and TG (or its extensions)
expect it to be always available for actions.

  - Assigning to **self**, this is pretty widespread in Kallithea and is an
absolute no-no in TG. All controllers in TG are allocated per process, so
assigning anything to controllers leads to race conditions when served in a
multithreaded environment and even in single threaded envs it might leads
to spurious data from previous requests. Data should only be assigned to
tg.request or tg.tmpl_context so all self.something should be properties
that read/write from on of those two places.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20160829/36bd2d7b/attachment.html>