<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">So the routing tries to access an index method.<br>
<br>
In the API code, the JSONRPCController parent class of ApiController<br>
is supposed to direct the calls to the correct method, but it seems we<br>
do not enter that class.<br>
<br></blockquote><div><br></div><div><div>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).</div><div> </div></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
I have seen in the TG2 documentation that typical, recommended, usage<br>
is different than what Kallithea is doing, and I think we should<br>
investigate if we can adapt our code base to such best practices<br>
eventually, but in the short term I think we should try to make the<br>
existing code base work.</blockquote><div><br></div><div>There are three major things that Kallithea does that are different from usual TG apps:</div><div><br></div><div><div> - 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.</div><div><br></div><div> - 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. </div></div><div><br></div><div> - 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.</div><div> <br></div></div></div></div>