Why TG2 over Pylons for new projects
Sanjay
I am a business application developer using TurboGears 1.x since long.
I had made up my mind to start learning TG2 until I discovered the
book at http://pylonsbook.com/ yesterday. Why TG2 over Pylons, is my
dilemma now. Some comparison in my mind is:
For TG2: TG2 is more definitive in terms of default choices (Genshi,
MochiKit).
For Pylons: Pylons book is also guiding for the default choices Maco
and YUI. In fact, Maco and YUI seem stronger then Genshi and MochiKit
in certain areas.
For TG2: The documentation of TG is vast
For Pylons: The book seems definitive on first look
For TG2: TurboGears has more components for users like ToscaWidgets,
TurboMail, TurboTinyMCE. And because it has more users, it will
continue to have more components.
For Pylons: No idea
For TG2: TurboGears has more users who would eventually migrate to TG2
For Pylons: No idea
Curious to know more points, and views on the above points, which
would enable me to take a decision on focusing on which one first.
thanks
Sanjay
Felix Schwarz
> For TG2: TurboGears has more components for users like ToscaWidgets,
> TurboMail, TurboTinyMCE. And because it has more users, it will
> continue to have more components.
> For Pylons: No idea
Upcoming TurboMail 3 will work with Pylons, too (and for that matter with
command line apps, plain CGI scripts, Django, ...).
fs
Jorge Vargas
says) is to provide as many alternatives to the components as
possible. And TG's philosophy is to provide the best of each
component. Therefore anything implemented in pylons can become the
best component suited for TG2. So when the decision was made the
winning argument was that pylons philosophy was more in line with
cherrpy's for TG2 needs.
Last but not least you don't need to know pylons to use TG2, just as
you don't need to know cherrypy for using TG1.
On Sat, Aug 2, 2008 at 1:03 AM, Sanjay <skpa...@gmail.com> wrote:
>
> Hi All,
>
> I am a business application developer using TurboGears 1.x since long.
> I had made up my mind to start learning TG2 until I discovered the
> book at http://pylonsbook.com/ yesterday. Why TG2 over Pylons, is my
> dilemma now. Some comparison in my mind is:
>
> For TG2: TG2 is more definitive in terms of default choices (Genshi,
> MochiKit).
> For Pylons: Pylons book is also guiding for the default choices Maco
> and YUI. In fact, Maco and YUI seem stronger then Genshi and MochiKit
> in certain areas.
it's Mako, and again this is the choice of the author of the book. For
example most pylons users hate authkit which is what the book focuses
on.
>
> For TG2: The documentation of TG is vast
> For Pylons: The book seems definitive on first look
>
well pylons is by far less complex, and a lot more distributed so you
have SA's docs, webhelpers, beaker, etc.
> For TG2: TurboGears has more components for users like ToscaWidgets,
> TurboMail, TurboTinyMCE. And because it has more users, it will
> continue to have more components.
> For Pylons: No idea
>
TW works on top of pylons. and you have implementation of MCE for TW,
and well you read the other reply about turbomail.
> For TG2: TurboGears has more users who would eventually migrate to TG2
> For Pylons: No idea
>
I don't see why this is relevant. TG2 build on pylons is not to steal
it's user base but to enhance it.
sams...@gmail.com
> Last but not least you don't need to know pylons to use TG2, just as
> you don't need to know cherrypy for using TG1.
hope we achieve it.
Jorge as a developer you might not realize it, but I don't think we
really accomplished not having to know cherrypy to use TG1. (Not to
knock TG1---it's a great framework and great accomplishment. And TG2
will be even better.)
I'm just not sure one can really get far with TG1 without spending
some time with cherrypy's docs and tutorial. I certainly had to do
so. In fact I had to go do the whole cherrypy tutorial about a week
or two into my TG project. I also had to read the sqlobject and
genshi docs multiple times.
Diez B. Roggisch
> On Aug 2, 10:04 pm, "Jorge Vargas" <jorge.var...@gmail.com> wrote:
>> Last but not least you don't need to know pylons to use TG2, just as
>> you don't need to know cherrypy for using TG1.
>
> If this is the goal of TG2---not having to know pylons to use it, I
> hope we achieve it.
>
> Jorge as a developer you might not realize it, but I don't think we
> really accomplished not having to know cherrypy to use TG1. (Not to
> knock TG1---it's a great framework and great accomplishment. And TG2
> will be even better.)
I have do disagree here! Even as a TG1 developer, I never dove into the
cherrypy-docs for most of my apps. I was just dimly aware of it being
the foundation of TG, and of course it appeared as namespace -
cherrypy.request for example.
But I never had to resort to the docs to understand something I didn't
understand in TG.
Now of course there might be apps that needed more insight into CP, and
I for sure can say that TG2 currently doesn't shield you from pylons.
And I'm not even sure if that's possible.
> I'm just not sure one can really get far with TG1 without spending
> some time with cherrypy's docs and tutorial. I certainly had to do
> so. In fact I had to go do the whole cherrypy tutorial about a week
> or two into my TG project. I also had to read the sqlobject and
> genshi docs multiple times.
To read KID and SO-docs was needed for sure, and I personally don't
think that we should try & make that need go away - we'd be writing
3rd-party docs over and over, without any benefit.
Diez
Christopher Arndt
> sams...@gmail.com schrieb:
>> Jorge as a developer you might not realize it, but I don't think we
>> really accomplished not having to know cherrypy to use TG1. (Not to
>> knock TG1---it's a great framework and great accomplishment. And TG2
>> will be even better.)
>
> I have do disagree here! Even as a TG1 developer, I never dove into the
> cherrypy-docs for most of my apps.
I have to disagree with your disagreement ;) For almost all TG apps I
built I needed to know about the cherrypy.request and cherrypy.response
object, for some about cherrypy.session and for even fewer apps about
cherrypy filters.
But I don't think that this a bad thing and that the underlying
applications server should be hidden from TG users. It might be a good
idea to build thin wrappers around some commonly available features,
like sessions and accessing request/response data. That makes it easier
to swap out the underlying implementation of those.
Also, I almost always found what I was looking for in the cherrypy docs
without too much effort and if not, I just looked into the source :)
Chris
Sanjay
> Well here is the thing. pylons goal (regardless of what that book
> says) is to provide as many alternatives to the components as
> possible. And TG's philosophy is to provide the best of each
> component.
me, who likes more caring and doesn't want to get lost in the world of
choices. But then, some concerms:
1. The defaults provided by TG2 (e.g. Genshi and MochiKit) could,
naturally, have been influenced by TG1, diluting TG's philosophy. (For
example, I came across a discussion at tg-trunk on "Mako vs. Genshi,"
where TG1 seemed to be an influencing factor.)
2. TG2 being a layer trying to be compatible with TG1, there might be
extra baggage not making sense for new projects.
3. While Pylons' philosophy is providing wide choices, can't just a
definitive book or documentation dictate the best choices? Is it that
TG2 is making life smoother by integrating components tightly, so that
developing an application is tangibly smoother, or LOC is lesser etc.
than Pylons? If so, then it seems a plus point in the comparison.
> example most pylons users hate authkit which is what the book focuses
defaulting to AuthKit?
thanks
Sanjay
Mark Ramm
> 1. The defaults provided by TG2 (e.g. Genshi and MochiKit) could,
> naturally, have been influenced by TG1, diluting TG's philosophy. (For
> example, I came across a discussion at tg-trunk on "Mako vs. Genshi,"
> where TG1 seemed to be an influencing factor.)
This is true. I like genshi, the syntax is clean, there is lots of
flexibility, and the context-awareness of it is great for helping to
protect against injection attacks. I think it's a good default, but
I'm aware that Mako is significantly faster in lots of cases, so it's
worth supporting both for those who "feel the need for speed."
But, you are right we have to balance backwards compatibility with
other considerations as we make decisions. But we have made a
conscious decision to "do the right thing" in every case -- even if it
means breaking backwards compatibility. TG2 is not a
re-implementation of TG1, it's an improvement on it.
> 2. TG2 being a layer trying to be compatible with TG1, there might be
> extra baggage not making sense for new projects.
There is very little extra "baggage" of this kind. TG2 is pretty
lightweight, but because we're able to commit to components we've been
able to make things like an authentication and authorization system, a
user management component, and I'm sure more components are coming.
These components can expect to user SA as an ORM, and can easily be
mounted in TG2 controllers via object dispatch.
> 3. While Pylons' philosophy is providing wide choices, can't just a
> definitive book or documentation dictate the best choices? Is it that
> TG2 is making life smoother by integrating components tightly, so that
> developing an application is tangibly smoother, or LOC is lesser etc.
> than Pylons? If so, then it seems a plus point in the comparison.
>
>> example most pylons users hate authkit which is what the book focuses
>
> Oh I see. Any other choice recommendations? I think TG2 is also
> defaulting to AuthKit?
TG2 is using repoze.who via a plugin that we've created that gives
repoze.who a default sqlalchemy model, and ties a number of helper
functions into that model.
Authorizaton is specifically one of the places that Pylons wants to
remain agnostic, they point you at a default ORM, but they are not
pointing you at a default auth provider. James (who wrote the book)
has his auth provider (authkit) but that does not mean that it's
anywhere near the default for the rest of the community. As was
already mentioned, there's quite a few people in the pylons community
who are loudly critical of authkit.
--Mark Ramm
sams...@gmail.com
On Aug 3, 3:56 pm, Christopher Arndt <chris.ar...@web.de> wrote:
> Diez B. Roggisch schrieb:
>
> > samsli...@gmail.com schrieb:
> >> really accomplished not having to know cherrypy to use TG1. (Not to
> >> knock TG1---it's a great framework and great accomplishment. And TG2
> >> will be even better.)
>
> > I have do disagree here! Even as a TG1 developer, I never dove into the
> > cherrypy-docs for most of my apps.
>
> I have to disagree with your disagreement ;) For almost all TG apps I
> built I needed to know about the cherrypy.request and cherrypy.response
> object, for some about cherrypy.session and for even fewer apps about
> cherrypy filters.
>
> But I don't think that this a bad thing and that the underlying
> applications server should be hidden from TG users. It might be a good
> idea to build thin wrappers around some commonly available features,
> like sessions and accessing request/response data. That makes it easier
> to swap out the underlying implementation of those.
read the cherrypy docs. I just think that for many users it's
necessary, and that it will almost certainly be necessary for users to
read external docs in TG2. It's not a bad thing, imho, but we need to
be aware of it.
sams...@gmail.com
Is TG2 really going to advocate mochikit? I certainly hope not.
Compared to other javascript toolkits mochikit seems to be on the
critical patient list. I know last time I brought this up I was told
that there was some work going on behind the scenes in Mochikit. But
come on, the last release was over two years ago. If there is active
work going on, it's a small fraction of the work going into any other
javascript toolkit.
Thanks
On Aug 2, 12:03 am, Sanjay <skpate...@gmail.com> wrote:
> Hi All,
>
> I am a business application developer using TurboGears 1.x since long.
> I had made up my mind to start learning TG2 until I discovered the
Dean Landolt
1. The defaults provided by TG2 (e.g. Genshi and MochiKit) could,
naturally, have been influenced by TG1, diluting TG's philosophy. (For
example, I came across a discussion at tg-trunk on "Mako vs. Genshi,"
where TG1 seemed to be an influencing factor.)
One thing I'm still a little curious about -- this MochiKit default isn't the case anymore, right? MochiKit hasn't had a release since April...of 2006! I know there's quite a bit in 1.4, but it's still swinging in the wind. It doesn't look like the quickstart template uses it...
Does TG2 have a default js framework? Should it? TW makes it pretty trivial to add all the major players, so it almost seems moot. That said, it's not so easy to easily support all the major css frameworks. This came up a month or so ago -- this seems like a good place for TG to be opinionated -- could definitely be a big boost for new users.
Mark Ramm
> read the cherrypy docs. I just think that for many users it's
> necessary, and that it will almost certainly be necessary for users to
> read external docs in TG2. It's not a bad thing, imho, but we need to
> be aware of it.
One difference in TG2 is that both TG2 and Pylons devs are working on
improving out docs, and both are using sphinx, so there's already a
lot more sharing going on than in the past. And there's a some
support for sphinx doc interlinking so that we'll be able to link to
other docs right from the TG2 docs.
Beyond that our upstream projects have largely started using sphinx,
and we're working with some of those people to try to improve their
docs as well. TurboGears 1 had a couple of upstream projects which
didn't have great docs, and it made TG1 user's life harder. We're
not there yet, but we're committed to making sure that does not happen
again with TG2.
--Mark Ramm
Jorge Vargas
>
> On Aug 2, 10:04 pm, "Jorge Vargas" <jorge.var...@gmail.com> wrote:
>> Last but not least you don't need to know pylons to use TG2, just as
>> you don't need to know cherrypy for using TG1.
>
> If this is the goal of TG2---not having to know pylons to use it, I
> hope we achieve it.
>
if you need it, therefore if you need some pylons component you are
able to use it, not forced.
> Jorge as a developer you might not realize it, but I don't think we
> really accomplished not having to know cherrypy to use TG1. (Not to
> knock TG1---it's a great framework and great accomplishment. And TG2
> will be even better.)
>
It seems this got misinterpret, you DO need to know some of CP to use
TG1 (as someone pointed out the request,response and session) but that
doesn't means you need to know CP to use TG1 (for example how are
those objects created, or how the URL is parsed to determine the right
method to call in the ObjectDispatcher). You don't need to go into the
details of it and you surely don't need to be an expert in CP. Same
thing goes for SO, SA, genshi, kid, etc.
> I'm just not sure one can really get far with TG1 without spending
> some time with cherrypy's docs and tutorial. I certainly had to do
> so. In fact I had to go do the whole cherrypy tutorial about a week
> or two into my TG project. I also had to read the sqlobject and
> genshi docs multiple times.
>
This was never the intention, the goal of the framework is to provide
a nice integration between the parts, you all you needed to do was
call the appropiate methods on the underlaying layer. So you need to
know the frameworks as an user not a developer.
There is no point in hiding the layer below, remember we have to make
complex things possible. Now if you are worried about having to learn
all the set of differences between CP, request, response,etc. objects.
This is already done.
http://pythonpaste.org/webob/differences.html#cherrypy-turbogears but
that's one of the components you shouldn't know about :)
>
> >
>
Ben Bangert
> MochiKit).
> For Pylons: Pylons book is also guiding for the default choices Maco
> and YUI. In fact, Maco and YUI seem stronger then Genshi and MochiKit
> in certain areas.
launch:
- Mako for templating
- SQLAlchemy for a RDBMS database ORM
- Routes for URL dispatch (Rails-ish in appearance, with URL
generation built-in)
These are defaults that are being documented. There is definitely a
difference in how definitive the choice is. In Pylons, we document
those because many will use them, but we expect quite a few people to
either not use them, or use them in a way that solves their specific
problem.
For example, Reddit uses a slightly customized dispatch scheme (their
controllers method name includes the HTTP method used, a quick 10 line
subclass), and they use their own ORM layer using SQLAlchemy. Knowing
the layout of Pylons and how the middleware stack works makes it a
breeze to come into their huge, and customized Reddit app, and see how
it works despite the rather hefty amount of customization they've
done.
Allowing this level of customization easily is a big goal for Pylons,
and why TG2 was able to fairly easily tweak it with a rather small
amount of code to have a TG1-ish API.
> For TG2: TurboGears has more components for users like ToscaWidgets,
> TurboMail, TurboTinyMCE. And because it has more users, it will
> continue to have more components.
> For Pylons: No idea
documents some default choices for you, it doesn't assume everyone
will use them. Thus writing "Pylons components" is somewhat
meaningless, since its hard to predict what the majority of people
have done with their Pylons project. TG2, like Django, is more
specific about the toolset it expects the user to be using, so future
TG2 components will likely not work if you deviate from the tools TG2
has chosen from the beginning.
While some TG2 components will be more flexible than others, clearly
if you dump all of the TG2 auth stuff for your own custom LDAP auth,
and 60% of the TG2 components require TG2 Identity, then you won't be
able to use any of those components.
In this area, the Pylons expectations and TG2 expectations are
slightly different, and by expecting more, TG2 enables re-usable
components, while Pylons.... not so much. Some toolkits work great in
both, like toscawidgets, and I'm sure many of the TG2 components will
require your app to be using the TG2 setup.
So, which one to use? It really depends on the application you're
writing, what you want to do with it, and what it needs to do. I
expect many TG2 users will become more familiar with Pylons and WSGI
middleware through TG2's use of it, and I expect TG2 users will
occasionally use just Pylons, and occasionally TG2 depending on the
app they're writing.
If you're writing a new app, where you get to determine the auth
system from scratch, its using an RDBMS, you like SQLAlchemy, and you
like object-style dispatch with controllers returning dicts, go with
TG2. As you note, you'll find components that will likely help your
task out.
Some times you will likely want to use just Pylons, like if you need
to deviate slightly or heavily from defaults for either legacy support
reasons, or unique requirements of your application that the defaults
don't help with.
Right now, Pylons 0.9.7 is getting closer (I've only been saying this
for a few months, I'm sure its getting truer the more I say it), and
there's little being changed in the API going forward, which means
we're focusing more on tools and other app support things. The scope
of both projects is definitely different due to the nature of project
assumptions in what you're using.
Hopefully this helps some. :)
Cheers,
Ben
Sanjay
Special thanks to Ben for making things really clear for me. Thinking
to start from TG2 and going to Pylons naturally.
Sanjay