Michael, I agree that catwalk should be it's own app at some point. However, I think that TG2 is benefiting from the marriage of Catwalk to TG2. TG2 recently grew a restful controller, and some new decorators because of the challenges in making Catwalk inside of TG.
I guess one of my goals with Sprox and Catwalk is really to push TG technology forward. I also want Sprox components to be easy for a developer to take a piece of and put it in their own code. This has been successful, and I have recently built tgext.admin, and tgext.crud with what I have learned about REST. The problem with making Catwalk it's own middleware is that I'd have to re-implement all of the rest dispatch, and I don't really have a desire to do that. Alternatively, I am looking into how Rum serves up content, and I may shoe-horn sprox into rum's rest controller. This is my plan for getting catwalk working on all of the other wsgi platforms, but for now, I am using it as a tool to help TG be the best it can be. cheers. -chris On Jan 15, 1:50 am, Michael Brickenstein <brickenst...@mfo.de> wrote: > Hi Chris! > > It easy to suggest something (without having the time to help). > But I think, this is related to some crucial design problem (at least > in the old version dbsprockets). > > You remember all the problems, we had with having a version of > dbmechanic for Pylons/TG1/TG2 and to fix bugs in all of them... > Essentially, I think Catwalk2 should be its own WSGI app. > It shouldn't need to be it's own framework like RUM, but maybe just be > a TG2 app, mountable in other TG2 apps. > I think, that should solve the problem (and would be a good test, if > TG2 is designed cleanly enough to support that). > > Michael > > On 15 Jan., 07:48, percious <ch...@percious.com> wrote: > > > Just so you guys know, this change allows people with mako, jinja, or > > chameleon.genshi default_templates to use "tg components" like > > tgext.admin and Catwalk. Without this, those libraries have to use XML > > () all over the place in their templates which also degrades > > performance. The default template already loads TW by default, so I > > am uncertain why having TW as a dep. would be a concern. > > > cheers. > > -chris > > > On Jan 14, 9:34 pm, Chris Miles <miles.ch...@gmail.com> wrote: > > > > On 15/01/2009, at 4:07 AM, Mark Ramm wrote: > > > > > if tg.config.use_toscawidgets: > > > > import tw > > > > tw.framework.default_view = tg.config.tw.framework.default_view > > > > > Makes sense, though you only want to do the import once, not on each > > > > request. ;) > > > > I was going to suggest that there should be no performance penalty > > > when repeating an import as Python only imports a module once. But > > > even though that is true, it looks like there is still the overhead of > > > processing the import statement and checking whether the import is > > > necessary, assigning the reference, etc. See > > > http://wiki.python.org/moin/PythonSpeed/PerformanceTips#ImportStateme... > > > > They suggest the use of a global for doing efficient lazy imports. > > > > Cheers, > > > Chris Miles > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
