On 8/31/06, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > On 8/31/06, Jorge Vargas <[EMAIL PROTECTED]> wrote: > > On 31 Aug 2006 08:24:29 -0700, Adam Jones <[EMAIL PROTECTED]> wrote: > > > > 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 > -- http://mail.python.org/mailman/listinfo/python-list
