On Jan 25, 6:50 am, Alberto Valverde <[EMAIL PROTECTED]> wrote: > Attached is a little diagram of how I' envisioning a TG > 1.0.x app
That looks good. Can you explain in a little more detail what the difference is between a RootController and a Controller? Why the distinction? > As you can see, my plan is to wrap a CP app in a WSGI app which will > be built by a function conforming to the paste.app_factory interface. > Although the CP app is a leaf node in the dispatching tree, another > WSGI app (being a CP wrapped one or any other one) can be mounted by > the *developer* with a cp.Tree or a paste URLMapper inside the app > factory so those apps can be encapsulated as a single app to the eyes > of a deployer/user. > > That whole "bunch" could be then deployed side by side other apps > easily by an *user*. Sounds like a perfect direction. But please, stick with the term "deployer". Users are always on the far side of a User-Agent. ;) > Fortunately for him, both the blog software he uses and the forum he > has just downloaded share the same system for deployment... By "the same system" you mean...WSGI? Paste Deploy? TG? In other words, at which point in the architecture would you start to say, "_un_fortunately for him, they don't share the same system."? > 1) Migrate the trunk to use CP3 with as little change as possible to > current architecture. I don't think it should be very difficult... > the only things needed to be adapted is the configuration system as I > believe CP3 and CP2 slightly differ in it's structure, port our CP2 > filters to CP3 tools and some "sed"ing to use the new names for > thiings in CP3. This means no change to current error-handling, > decorators, etc... I believe someone who knows well CP3 and is > willing to take a look at how TG's trunk is incompatible could be of > *great* help in this area (hint, hint... ;) There are a few such people. :) Happy to help. > All current TG unittests should pass before moving on to 2) Maybe > some tweaking or adaptation is needed, I don't know.... User apps > that use filters should be adapted to use tools instead. > Documentation for this must be written. I'll trade you better Tool docs for better TW docs. ;) I'm a bit lost on how the various components actually work: who calls whom when. > 2) Add to the resulting quickstart template a module with an > app_factory that builds a WSGI app out of the CP Root controller > loading it's TG style configuration file and merging it with a > *possible* paste.deploy config. This factory will sort-of replace > start-myapp.py > > What I mean by "possible" is that a single TG app doesn't really need > a paste.deploy config file and the CP configfile, built by the > developer, we're used to is enough. A paste.deploy config is needed > when a TG app distributed as an egg wants to be mounted side by side > in a bigger site. A a smart "tg-admin serve" command should be able > to load a single app inside an EGG and mount it at / without needing > an explicit deployment config. However, internally, "tg-admin serve" > would delegate to "paster serve" to load that EGG's app_factory entry > point. That sounds like an excellent direction. I would be quite interested in folding any such app_factory interface back into CherryPy itself. I think this is an area where we can co-develop quite well. For example, could this be solved by having the CherryPy Application class grow a new app_factory (class)method? > Some TODOs needed for 2: > > a) Some helper functions should be integrated in Turbogears to merge > the config file. Note that all server.* directives will not be needed > (and should make no effect if present) because the app will have no > knowledge of which server will be serving it. I have some > experimental code for this. If you're not using cherrypy.server to start and manage HTTP servers, then the various server.* config entries will be largely ignored (those config entries just set attributes, they don't invoke any code on their own); however, they should be set properly so that cherrypy.url() works when you're not in a request. Thanks for putting so much effort into this! Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
