> From trying to work with TG it seems like it would be very nice for > making a single coherent application like a wiki, a BB or a blog and > bloody awkward for designing a multi-purpose container like a CMS. > Django seems like it would be better for designing something more > sprawling and creates much more convenience and order for plugging > things in after the fact, but, and this is just me, except for that > one major flaw (to me) I like what I see as the elegance and > flexibility of TG a lot more.
I'm a bit more deployment oriented than programming oriented myself, so I understand this impulse. The thing that I appreciate about TG2 is that I'm going to be able to maintain, patch and hack web apps on it using my meager Python skills and a tool set with applications in the server environment as well as in the web environment. In designing infrastructure components like TurboGears, I think that good design is to make sure that there is a right way to do any given task within the scope of the tool, not necessarily to define what that way is. Ian Charnas is working hard on Tortuga CMS, described as a "pluggable CMS," to have a beta out by the end of the year (the last I knew). This isn't a trivial task, but I'd be willing to bet that he's had an easier time of writing a CMS for TG2 - despite the evolving API of some components - than the Plone Team did writing a CMS for Zope. I'm not slamming Zope. They've done a lot for the Python community. If learning to write for Zope was as easy as writing a TurboGears app, though, we would have many fewer Python frameworks in the market and under development. Not to weigh down Ian with my expectations, but I think that Tortuga is what you are waiting for in terms of CMS functionality and/or being able to write plugins for a registration interface as opposed to writing to an API, but I may be reading more into the definition of "pluggable" than the authors intend for the beta release. I think that Python/TurboGears is more fairly compared to PHP/Pear than PHP/Joomla. That's not a one to one either because Python and PHP do different things, so Pear and TG2 address different needs, but that's more fair than comparing a tool chain to an application. I'm hoping that Python/TG2/Tortuga will shape up to be a stack that compares favorably to PHP/Pear/Horde and Python/Zope/Plone once developers have had some time to play with the API. It's not going to deploy on any free or $5/month hosting packages, but I view that as a benefit, because I'm going to be able to integrate some computationally intensive server-side logic to improve the user experience - like AIs in web-based games or user agents for filtering web content - that won't be available on those platforms. There's a reason that the functionality you are asking for is available 'there' and not 'here'. 'There' is a stable application. It's pretty much as good as it's going to get. Any improvements will be incremental. 'Here' is a tool chain... in beta. It's already sufficiently feature-rich that we feel compelled to compare it to the other, but it's not really comparable. The programming layer is barely complete and the application layer isn't even available yet. We can see what we'll be able to do, but it may be another year before we'll be able to do it easily. I know that documentation is a high priority for the TG team, so I'm sure that the mechanisms will be described more explicitly than they are now, but I'm pretty sure that a copy the files and click on the widget in the administration interface implementation will come to TG from a whole different layer of the application stack. Chris --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
