On 12/21/05, Sylvain Hellegouarch <[EMAIL PROTECTED]> wrote: > > Hi Kevin, > > > > > As I alluded earlier in the thread, I *do* plan to have a way to plug > > in a different template system, but primarily for the purpose of > > backwards compatibility and easier transition to TurboGears. > > I like the sound of that idea since it has been the core idea of CherryPy > itself > since the very beginning. Being able to plug and play what fits your needs. > I'd > like for instance replace Kid by XSLT for my personnal use. > > - Sylvain
Case in point. I have three Quixote applications using Cheetah and a homegrown SQL generator. I see TG and like its clean controller design, forward-compatibility for Ajax, SQLObject which has stablized since last year, and an active development community that has many more features almost done. But I'm not too happy about Kid. Yes, my *output tags* have to be valid HTML, but why should my control structures be (#for/#if/#def/#extends). The significant word (py:for) is buried in a tag attribute where it's easy to miss. I'll have to put comments around every for-block and if-block to make them stand out. And Kid doesn't have if/else! Now, if TG had a simple way for me to plug in a Cheetah engine, yoo hoo! Even if it didn't ship with TG for philosophical reasons, that would be fine. I do believe in "one way of doing things". I just don't believe in adding artificial barriers to prevent people from doing other things. Right now you have to completely rewrite @expose or push your own template.view() into TG: not cool. I've added a plugin architecture outline to the Cheetah ticket (#214). Unless I'm mistaken, it's dirt simple to port the existing Kid code to this, and then people can also write drivers for any other template system they like. TG wins because it's fundamental goal hasn't been violated: a "one way to do it" that works out of the box. But TG also wins again because a secondary userbase will come to it, those who absolutely refuse to use Kid. Otherwise users have two choices. Suck it up and use Kid, or port all of TG's other interesting features to <Other Framework>. That's really what "Don't use TG if you don't like Kid" means. I'd like to see this plugin philosophy extended to any other major areas of controversy that come up. I don't see the SQLObject dependency as significant at this point: there is no clear alternative. But it could be an issue in the future. The other potential areas are things that haven't stablized yet: forms, identity, sessions, etc. Hopefully the final contenders will be flexible enough to work for everybody, but if not, people need an easy way to substitute their own, and this should be documented with examples. -- Mike Orr <[EMAIL PROTECTED]> ([EMAIL PROTECTED] address is semi-reliable)
