> > Yes, I still don't know if it cares about the config options, the > config object was quite pervert (wrapper of a wrapper of a > DispatchingConfig used as a StackedProxy) and I'm afraid that I might > have broke something. >
Well, to be honest the old config had a strange (and I though very problematic) problem in that it allowed dotted notation for lookup, and mostly but not always for setting config options. Anyway, I think the config object issues did not turn out to be nearly as difficult to maintain as the load order of the quickstarted middleware setup files. But all that was inherited from Pylons, and we should think about making them cleaner in new quickstarts someday. > > I'll be really glad to anyone that has a few hours to invest testing > the pylons-less branch on any applications that he has available. > Just keep in mind that it is based on TG2.1.4 so the application > itself has to be compatible with TG2.1.4 > Even pylons based controllers should work, just check that > tg.pylons_compatible is True. > Disabling it makes the app go faster at the price of not being > compatible with Pylons related Controllers (XMLRPCController for > example) > We should probably do this the oposite way (since most existing apps will not have tg.pylons_compatible already, so they will break on upgrade to this branch if they use the controllers. So for example we could set: tg.no_pylons_controllers = True In quickstart, and tell people about it as an optimization when they upgrade, but not break their code. > My current target for the branch is to achieve 100% code coverage on > the TG module. > That's great! -- You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
