Turbogears to Pyramid

159 views
Skip to first unread message

sajuptpm

unread,
Feb 1, 2012, 2:36:27 PM2/1/12
to pylons-discuss
HI,

I have a project developed in turbogears, i want to move it to
Pyramid, is it possible ???
I am using following feature of TG2
controller
sqlalchemy
tg2env
developement.ini
Not using any template system, since UI developed using EXTJS

Reason to this change is, Pylons stopped further support for TG2.

cd34

unread,
Feb 1, 2012, 3:04:21 PM2/1/12
to pylons-discuss
On Feb 1, 2:36 pm, sajuptpm <sajup...@gmail.com> wrote:
> I have a project developed in turbogears, i want to move it to
> Pyramid,  is it possible ???

> I am using following feature of TG2
> controller

The closest thing to the controller structure from TG2 are handlers.

while I documented a Pylons 1.0 -> Pyramid the first week Pyramid
became generally available, the app in question was originally a
TurboGears 2.0 app:
http://cd34.com/blog/framework/pylons-1-0-to-pyramid-1-0a1/ You might
also look at the Ahket scaffolds which set up a Pyramid project to
look a lot like a Pylons project.

> sqlalchemy
supported

> tg2env
I believe this is just a wrapper for virtualenv, and is the suggested
method for installing Pyramid.

> developement.ini
Both development.ini and production.ini files are supplied.

> Not using any template system, since UI developed using EXTJS
You can use Response objects to emit raw html created from your
controllers.

> Reason to this change is, Pylons stopped further support for TG2.
TG2 was based on Pylons, but, Pylons is still available, but, not very
active anymore.

Christoph Zwerschke

unread,
Feb 1, 2012, 3:17:08 PM2/1/12
to pylons-...@googlegroups.com
Am 01.02.2012 20:36, schrieb sajuptpm:
> Reason to this change is, Pylons stopped further support for TG2.

There may be reasons for switching from TG2 to Pyramid, but that is not
a valid reason. Pylons will not be a requirement any more in TG 2.3.

There had been plans to create a "next generation" TG based on Pyramid,
but that won't happen in the near future since the TG community is
currently focusing on improving the existing TG2 and staying compatible.

-- Christoph

Mike Orr

unread,
Feb 1, 2012, 3:19:07 PM2/1/12
to pylons-...@googlegroups.com
On Wed, Feb 1, 2012 at 12:04 PM, cd34 <mcd...@gmail.com> wrote:
> On Feb 1, 2:36 pm, sajuptpm <sajup...@gmail.com> wrote:
>> I have a project developed in turbogears, i want to move it to
>> Pyramid,  is it possible ???
>
>> I am using following feature of TG2
>> controller
>
> The closest thing to the controller structure from TG2 are handlers.

Actually, the closest thing to controllers is view classes.
pyramid_handlers is one way to manage view classes, but increasingly
people are "doing it themselves" with @view_config.

--
Mike Orr <slugg...@gmail.com>

Carlos Daniel Ruvalcaba Valenzuela

unread,
Feb 1, 2012, 4:15:59 PM2/1/12
to pylons-...@googlegroups.com
I think a sensible approach is to stay with turbogears if you have
already invested time on it for that project, turbogears is not going
anywhere any time soon, recent development has even decoupled the
codebase from pylons if that is what bothers you, but if all you want
is to migrate it to another framework (for whatever the reason, also
saw your post on the django list) you may want to use something like
Akhet or RapidGuiza which are pyramid templates which works very
similar to TG2 from the controller point of view.

Regards,
Carlos Ruvalcaba.

Jonathan Vanasco

unread,
Feb 2, 2012, 3:39:21 PM2/2/12
to pylons-discuss


On Feb 1, 3:19 pm, Mike Orr <sluggos...@gmail.com> wrote:

> Actually, the closest thing to controllers is view classes.
> pyramid_handlers is one way to manage view classes, but increasingly
> people are "doing it themselves" with @view_config.

Could you point me to something where someone "does it themselves"?

Just wondering what the implementation would be.

Jesse Dhillon

unread,
Feb 2, 2012, 4:03:59 PM2/2/12
to pylons-discuss
An example of rolling your own controller class:

from project.lib import BaseController

class MyController(BaseController):
def __init__(self, root, request):
self.request = request
# any other statements to be executed before every view

def get_index(self):
return {
'global_obj':
self.request.registry.settings.get('some_global_obj')
}

in your configuration:

config.add_view('project.controllers.MyController', attr='get_index',
method='GET')

If the view object is a class, then __init__ is called first, then
__call__ unless an attr arg is supplied to the view config. Does this
help you at all?

Jesse

Mike Orr

unread,
Feb 2, 2012, 4:11:39 PM2/2/12
to pylons-...@googlegroups.com
The demo app for the upcoming Akhet 2 does this.
https://github.com/mikeorr/akhet_demo

Download it, make a virtualenv, run "pip install -e ./akhet_demo", and
"pserve development.ini".

By view class, I mean any class that's structured for view methods,
with @view_config on each method.

--
Mike Orr <slugg...@gmail.com>

Jonathan Vanasco

unread,
Feb 2, 2012, 5:20:12 PM2/2/12
to pylons-discuss
mike- thanks. clears it up.

i'm still using a mixture of @action and , increasingly,
render_to_response.
Reply all
Reply to author
Forward
0 new messages