<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 28, 2016 at 12:34 AM, Mads Kiilerich <span dir="ltr"><<a href="mailto:mads@kiilerich.com" target="_blank">mads@kiilerich.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Do you have an idea of how much work it will be to make a full production ready migration?</blockquote><div><br></div><div>Well, no :P</div><div>I think 90% will probably be ported in a bunch of days, the remaining 10% will probably require to rewrite some parts. For example I saw that the API controller pretty much overrides most of what was Pylons WSGIController and works at pretty low level, that will probably have to be rewritten. Even though it can probably be achieved in a day or two.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> Do you already now see any big tasks in the horizon? </blockquote><div><br></div><div>Surely the routing should be ported from routes to turbogears routing. Currently I just put one huge TG controller that intercepts everything and then through routes dispatches requests to controllers it creates on the fly and exposes their methods when requested. While we should mount all the controllers as subcontrollers and @expose their templates instead of manually calling render at the end of controllers. Also TG takes for granted that controllers are singletons and never instanced twice, so modifying a property of a controller introduces race conditions, custom data should be stored in request object, while Kallithea stores things as controller attributes pretty often.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Now when you have looked more at our code base, in what areas do you think we could change our implementation to benefit more from TG ... and what benefits would that give us?<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>There are a lot of things that are custom written in Kallithea and that TG provides out of the box, porting kallithea code to them would greatly reduce code size and provide a standard implementation for people willing to contribute. The main parts that came to my mind are:</div><div><br></div><div>- authentication (TG auth is based on top of repoze.who which if I'm remember correctly was one of the targets of Kallithea to move to repoze.who)</div><div>- authorization (TG provides predicates for authroization like @require(not_anonymous()), @require(in_group('groupname')) and so on that are currently custom implemented in Kallithea</div><div>- JSON based apis, TG has support for @expose('json') and @decode_params('json') for controllers that have to receive and respond json instead of manually encode/decode everything</div><div><br></div><div>Generally speaking TG is more high level than Pylons so probably many things that are custom in kallithea are probably available in TG itself and relying on the framework for those would greatly reduce the maintenance effort but will require a greater porting effort :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><font color="#888888">
/Mads<br>
</font></span><br>
PS: I guess we could make a migration look even more painless by temporarily introducing a mock pylons module that just call through to TG?</blockquote><div><br></div><div>That's actually what I did at <a href="https://bitbucket.org/_amol_/kallithea-tg/commits/3d03249816b8e0143e4cc7f8a4d955d561bd54a6#Lkallithea/config/app_cfg.pyT35">https://bitbucket.org/_amol_/kallithea-tg/commits/3d03249816b8e0143e4cc7f8a4d955d561bd54a6#Lkallithea/config/app_cfg.pyT35</a>  to make webhelpers.pylonslib.secure_form work, I faked TG as the pylons module so that it has been able to find pylons.session which is actually identical to tg.session as both are Beaker sessions.</div></div><br></div></div>