Turbogears2 migration: API calls

[Thomas De Schampheleire]

On Mon, Aug 29, 2016 at 10:15 AM, Alessandro Molina
<alessandro.molina at gmail.com> wrote:
>> 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.

Thanks!

>
>>
>> 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:

Thanks for this list, it is very useful to get such an 'audit'.

>
>   - 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.

To use ObjectDispatch, we'd need extensive usage of the _lookup method
inside the controller, is that correct?
http://turbogears.readthedocs.io/en/latest/turbogears/objectdispatch.html#the-lookup-method

>
>   - 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.

Can you give examples from the Kallithea source code? In the
controllers I only find three files that have assignments to self:
feed.py, api/__init__.py, journal.py.

Thanks,
Thomas