TurboGears experiment
Mark Ramm
to get together next week and sprint on a TurboGears related project,
so I thought I'd let everybody here know about.
We're thinking that it would be a worthwhile experiment to try to
reimplementing the core TurboGears API on top of Paste/Pylons and see
what we get.
It may be something useful, or it may not, but we figured it' is an
interesting experiment at least.
There are a couple of useful possibilities that we'd like to explore:
Could you have object style dispatch by default, but which can be
overridden with a routes style file for particular paths?
Can we make testing even easier by implementing a Python template
engine, which works like @expose(allow_json=True) to pass the python
dictionary right through? This would be useful if you want to use
your controllers from python, as well as for testing).
Can we make transaction handling happen in middleware, and have the
defaults be more easily overridden than they are now? So that some
controllers will be automatically wrapped in a transaction, while
others which only read from the DB, or don't touch the DB at all are
not wrapped in a transaction.
If you're interested in joining the sprint remotly, or just want to
talk about the idea, you may want to joing the sprint's google group.
http://groups.google.com/group/pygears/
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
Alberto Valverde
I think the group is private.... Maybe it'll be a good idea to open
it up so interested people can join ;)
Alberto
Mark Ramm
I had it private for a bit, back when we hadn't talked to you yet ;)
--mark
Alberto Valverde
On Jun 18, 2007, at 6:49 PM, Mark Ramm wrote:
>
> It's open now.
>
> I had it private for a bit, back when we hadn't talked to you yet ;)
>
OMG! Mutiny in the TG!! :D
Alberto
Mark Ramm
Yea, I was like "hey let's try this experament -- it might be useful
for thinking about how TG 2 will look" and everbybody was like "Let's
build TG 2." Which of course was getting the cart in front of the
horse, especially since we only had the idea on Thursday night ;)
--Mark Ramm
iain duncan
TG2 will still use CherryPy 3 thought correct? ( Sorry if that seems a
stupid question from the experiment description. )
Iain
Jonathan LaCour
>> Yea, I was like "hey let's try this experament -- it might be useful
>> for thinking about how TG 2 will look" and everbybody was like
>> "Let's build TG 2." Which of course was getting the cart in front
>> of the horse, especially since we only had the idea on Thursday
>> night ;)
>
> TG2 will still use CherryPy 3 thought correct? ( Sorry if that seems a
> stupid question from the experiment description. )
Well, the code produced in the sprint won't use CherryPy at all, in all
likelihood. However, as Mark said, this isn't necessarily going to turn
into TurboGears 2.0. Part of the reason that I am participating in this
sprint is because I'd like to see what a TurboGears on top of Pylons
would look like. If it looks great, and works well, there is a good
chance that I would push for it to be the beginnings of TurboGears 2.0.
TurboGears 1.1 is almost ready, and will be using CherryPy 3.0 for sure,
including all of the great things that CherryPy 3.0 brings to the table.
TurboGears 2.0 is far enough out that no one really knows what it will
be like :)
--
Jonathan LaCour
http://cleverdevil.org
Mark Ramm
> > stupid question from the experiment description. )
>
> Well, the code produced in the sprint won't use CherryPy at all, in all
> likelihood. However, as Mark said, this isn't necessarily going to turn
> into TurboGears 2.0. Part of the reason that I am participating in this
> sprint is because I'd like to see what a TurboGears on top of Pylons
> would look like. If it looks great, and works well, there is a good
> chance that I would push for it to be the beginnings of TurboGears 2.0.
Well, there's a good chance that the code we generate at the sprint
will use CheryPys WSGI server, since that's the way pylons does things
now. But yea, we probably won't be using very much more of CherryPy
in this experimental branch.
But you never know. Alberto has suggested that we just use CherryPy
3's object dispatch directly -- though that would be more attractive
if CP3 had an engine-less mode. (Which it might grow later, who
knows.)
iain duncan
Ok, cool. I'm pretty impressed with the stuff in the new CherryPy book,
and with the quality of the book itself. So it would be sad not to keep
leveragiong all that good work!
Iain
Mark Ramm
> and with the quality of the book itself. So it would be sad not to keep
> leveragiong all that good work!
Yea, there's lots of good stuf in Cherrpy 3 thats for sure. Robert
Brewer has done a fantastic job, and there is a lot of convenient
features, and good stuff in there. At the same time the Pylons guys
have a lot of great stuff too, and collaborating with them more
closely will bring us a lot of good new stuff.
Perhaps we can have the best of both worlds, or perhaps we'll have to
make a choice. That's part of what this whole experiment is about --
do we have to choose, and if we do what does the choice look like in
real code.