On 8/31/06, BJörn Lindqvist <bj*****@gmail. comwrote:
On 8/31/06, Jorge Vargas <jo**********@g mail.comwrote:
On 31 Aug 2006 08:24:29 -0700, Adam Jones <aj*****@gmail. comwrote:
I believe that is the most important part of TG, taking the best of
the best, and letting the framework adapt and morphe.
for example noone plan to move to SA, 0.1 came out a couple of people
took and look and like it, then 0.2 was "mature enough" so people
started thinking about the migration. after that some code was made
and now we have TG with SA, eventually it will be the default.
Same with templates, kid is really weak at generating non-xml, it has
a plain text serializer but the input must be xml so that's overkill.
So a new template frontend (chettah was born).
Someone ones said on the mailing list TG is the Ubuntu of web
frameworks, and I think I'll add and you can strip down the kernel and
it wont break :)
But that is not really true. If you use Cheetah instead of Kid, you
lose out: No widgets,
that is not correct all widgets have a template attribute which yes
it's kid but replacing it is as simple as changing it's value to a
Cheetah template.
no auto-generated code and the (incomplete)
that is not correct, the only part I can think about is not having
default templates, which are just a demostration/sample app. other
then master.kid I don't think any of the others are used, and the
concept of master.kid doesn't exists in cheetah I think,
if you are really concern about this please create pasteScript with
the chettah default templates and I'll make sure it gets into the
trunk as the sqlalchemy autogenerated code did.
documentation won't apply anymore (it assumes Kid templates ofcourse).
actually no, you get a dict of values into your template, now if your
talking about teaching how to use the "other templating engines" then
I suggest you read their docs, because at that point TG changes
nothing (except 2 or 3 variables that are populated by TG into the
templates)
If you use SQLAlchemy instead of SQLObject, no identity framework,
not true it was commited together with the support for SA 0.2
no administrative tools (tg-admin sql, CatWalk etc)
ok first tg-admin sql is just a wrapper around sqlobject-admin so the
lack of that tool is actually a lack in SA.
about Catwalk and model designer they where created to work with SO,
in fact they are so couple that probably a new tool will be written.
and no documentation.
yes we had many troubles with that we have went from one system to
another but we settle with rest and are going to use moinmoin for a
while until docudo is ready. all the docs are being integrated there
and as we have said there wont be 1.0 until we have lots of docs.
If you use prototype instead of MochiKit... I have no idea what
happens
MochiKit is the most decouple part of the project you can include
almost anything as long as the javascript doesn't collide with
eachother (for example there was a problem with prototype and MochiKit
used together a couple of months ago)
and using another webserver than CherryPy isn't possible right
now, I guess?
there have been some initiatives (experiments mostly about it, and
docs about it on trac) and they work although changing CP is the most
challenging part and I don't think anyone involve with the project
wants that, although you are welcome to try, if X becomes a
replacement for CP we'll migrate to it. all that needs to be done is
write the method/paths logic and make X handle dictionaries as return
values.
you may as well make your own smash up of tools if you want to replace
all components
a couple of emails below you said you just wanted to say that there is
no infix replace and I never said it was like that I said if you want
to change it go ahead the framework wont stop you like happens with
RoR or Django.
at last I dont' agree with you that making the framework support more
things makes it more complex, TG design is genious in that part for
example all template plugins (which are small package define a small
set of variables (actually a class, or abstract class or interface,
whatever you want to call it.)
http://www.turbogears.org/docs/plugins/template.html so after that the
rest of the code doesn't cares about which render is actually going to
be use.
and that's why the same TG app can render with more then one
templating engine at the time. in fact you can have the same method
render with 2 different engines if you may need it.
In fact, if you decide to replace so many modules that TurboGears
depend on, what do you gain in using TurboGears at all? It seems like
the TurboGears developers have a lot of work to do, (and a lot of
documentation to write) if they want to make their framework as easy
to use as others (ie: Django) that takes a more holistic approach.
TurboGears more seem to be like emacs than Ubuntu - infinitely
customizable...
In the future both Rails and TurboGears will probably be great. But
since someone mentioned Rails moving to YARV, and TurboGears moving to
SQLAlchemy and Markup, it seems to me that they are both in a state of
flux and not quite ready yet.
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
