On Jan 25, 2007, at 7:37 PM, fumanchu wrote:
> > 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? Well, actually that distinction is present in 1.0 but I'm not sure if a migration to 3.0 will remove it completely. AFAICT it's only purpose in 1.0 is implementing some loggers and setting is_app_root (though a grep on tg's source hasn't revealed where else that attribute is looked up.. :-/, does CP do something with it?) > >> 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. ;) Ok. > >> 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."? I meant Paste Deploy & WSGI. WSGI for the protocol and Paste Deploy for the (app|filter|server)-building interfaces needed by paster. I like Paste Deploy interface because I see them as only a very basic way of saying what an app factory should expect and return, easy to implement and powerful enough. You don't even need Paste to mount an app that implements an app factory! Just call it with a dict as first parameter and some keyword args and it will return a wsgi app which you can further manipulate. Besides that, it already implements utilities for loading apps directly from and egg, etc... which are quite handy. It's config file syntax might not be the prettiest to some eyes but I'm pretty sure it can be worked out if needed, what I'm looking at is it's interface for building (WSGI) apps and connecting them to a server. > >> 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 >> things 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. Which is very nice! :) > >> 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. Are you meaning TG or TW?, if the later (toscawidgets) I think discussing it's docs deserves another thread... ;) If the former then I must say I need to do some homework and dive into TG to refresh my memory.... grep says TG only uses 4 filters: $ grep -r "^class.*Filter" turbogears/ | egrep -v "(MochiKit|\.svn| \.pyc)" turbogears/database.py:class EndTransactionsFilter(BaseFilter): turbogears/startup.py:class VirtualPathFilter(object): turbogears/startup.py:class NestedVariablesFilter(object): turbogears/visit/api.py:class VisitFilter(BaseFilter): I can't remember any other filter we use... these filters are initialized and stacked in startup.py IIRC. I think they can be easily rewritten as Tools. I believe that adjusting our config system to what CP3 uses now will be the "hardest" part in a CP3 migration > >> 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? Hmm, only if entry_points can be made to point to a classmethod which I believe they can't... However, I think CP3 quite well supports being wrapped in an app factory as it stands right now. I would rather have the app factory under the application developer's control (editable in his own app's source) because it's a (another) great place to "manually" stack middleware, dispatchers... and do any sort of stuff that should occur only once in the app's lifetime. This is what Pylons is doing for example, > >> 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 the info (I'll be probably be needing many little snippets like this in the future... ;) > Thanks for putting so much effort into this! You're welcome! It seems (by CP's Trac timeline) that it's reciprocal... :) Alberto --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
