We are almost done with our school project that uses TG, and I wrote a small "lessons learned"/retrospective analysis of what went right and what went wrong:
http://www.writely.com/View.aspx?docid=bdfmvvthd98nc Of course it may be overly critical and subjective, but there wasn't really enough time to go to great depths in various issues during the implementation and frustration came about more easily than it typically does with completely "voluntary" open source projects. :-) I copy pasted it here, for those that care: TurboGears, lessons learned Author: Ville Vainio, [EMAIL PROTECTED] Introduction We (4 people + "customer") implemented a simple "poll server" web application with TurboGears 0.9x pre-version. It was a non-critical school project. Part of the motivation of choosing TurboGears over e.g. Django was to learn the individual components (e.g. sqlobject) that could be usable outside web development space - none of the people were professional web developers (beginner level at best), but Python is used for various applications also professionally and one of the implementors is a long-time python user. None of the components apart from Python was familiar to anyone in the team prior to project. Nontechnical reasons for selecting TG were the apparent momentum it was gathering, and the already legendary "20 minute wiki" video. User experience - the good It was very easy to get started, get the databases going etc., despite the fact that we were dealing with pre-alpha software initially. catwalk was a big plus. The MVC approach works great and is simple and straightforward enough for even inexperienced python programmers. Identity framework was easily pluggable "after the fact", i.e. after most of the application logic was already in place. User experience - the bad sqlobject was confusing, apart from the simple use cases (where queries are done by MultipleJoin in model.py). Name mangling was irritating, there was no one "obvious" way to spell a field name and mistakes were commonplace. Selects just didn't work as expected until done directly with strings. Had we started a bit later, we'd probably have went with SQLAlchemy since it seems to be considered the "better of breed", but it was too late in the development cycle and it would have been too much of a hassle (considering the inevitable "unexpected" problems). User experience - the ugly Kid. Excessive xhtml and well-formedness requirements were an annoyance, even if they can be seen as benefits in more "serious" projects. The markup was unintuitive in its XML-ness, even if this again can be a benefit when the web frontend is implemented by people that can't run the code (and as such have to render it directly in the browser). The other drawback of kid is that it's useless for our everyday non-html templating tasks. Templating is highly subjective, but authoring Kid templates was unpleasant and not as simple as templating could be (the author of this text has previous experience with EmPy, which gets the job done with much less markup and complexity). Conclusion TG is great packaging with not-so-great individual components. We were conscious of the risks involved with alpha-level software, but the stability was not a problem most of the time. The area where more maturity would have been a benefit is using the "alternative" components (cheetah for templating and sqlalchemy for ORM), for which there was too little real-world experience and us experimenting with that area could have easily backfired and endangered our schedule. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
