Hi all, I was planning to write something soon to share what my thoughts have been recently regarding TG's future but been very busy with paid work (and will be until late february). Anyway, here is an update to bring up some discussion and maybe clear some uncertainties.
After thinking about it, meditating the past thread regarding this same issue, reading some blogs/wikis and experimenting, I think TG 1.1 (yep, 1.1) could start migrating to CherryPy 3 and a PasteDeploy style configuration file for deployment. Some of my confusion regarding CP3 was to the fact that I wanted it to do something it was not designed to do: that is, make CP applications (those composed of a RootController which mount other controllers as attributes, etc) being able to dispatch to another WSGI app. Although it is possible, there is a problem if the downstream app turns out to be a CP3 wsgi-wrapped app because it will smash cp's globals being set by the upstream app and might cause unintended consequences. So yes, this means TG controllers will not be WSGI callables per-se like I announced in the IRC chat on Jan 3rd :( However, CP3 provides other mechanisms for this kind of dispatch (cp.Tree) and there are other tools that can be used to do it (paste's URLMapper, for example). There's no need for TG/CP apps (without the WSGI wrapper) to act as mixed WSGI application/ middleware creating havoc inside CP , if this kind of behavior is needed then proper middleware should be written using your library of choice to sweeten WSGI. Attached is a little diagram of how I' envisioning a TG > 1.0.x app 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*. The difference I'm trying to emphasize here between developer and user might be better explained by a use-case: Developer Jane has built a Forum application using TG > 1.0.x and decided to use CatRun3000 (which is a WSGI app built in who-cares- what framework) as the admin interface for her app so she has mounted it at /admin (relative to the forum app). This mounting takes place inside her apps' app_factory (yeah, Pylons' way... ;) Now she distributes this composite app as an Egg and user Joe decides he want's to integrate it in his site. Joe isn't a programmer but he likes blogging his butterfly-hunting sessions and has congregated a passionate bunch of people who share his interests so Jane's Forum software has appeared like god-sent and it'll be perfect for his site. Fortunately for him, both the blog software he uses and the forum he has just downloaded share the same system for deployment, so he easy_installs Forum and edits 4 lines in his site configuration file (paste deploy style), mounts the forum at /forum, restarts and voilá. This user/developer distinction is very important IMO... part of the success of PHP, for example, is that it allows any computer-savvy user to download WordPress, decompress in his shared-host account, and install. Doesn't even need to know how to program to do that. So here is my proposed plan for action in chronological order: 0) Backport the 1.0 widgets back into the trunk. The widgets in the trunk are *broken* by my early genshi integration experiments. We have two choices: introducing ToscaWidgets into 1.1 (will break most 1.0 apps) or porting the 1.0 widgets which are working fine ATM (albeit its design limitations). This means widgets could only use Kid for their templates and genshi's ET should be used to display widgets in Genshi templates. Maybe the "ET" step can be automated but I'm not very sure as it must only occur when displaying on a page template and 1.0 widget's don't know whether they are being displayed in a page template or inside another widget. All current TG unittests should pass before moving on to 1) User apps should not notice this change. 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... ;) 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. 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. 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. b) The "tg-admin serve" command must be implemented. This means "start-myapp.py" will be deprecated, an alias could be implemented for backwards compatibility by making that script delegate to "tg- admin serve". c) TG's startup-hooks and extension loading should be slightly refactored so this step can be done by calling a function from the user's app_factory. d) Application devs' start-myapp.py will need to be adapted for this change, it's not hard at all, just move that logic to the app_factory. At this point we should have achieved: 1) A migration to CP3. This means, apart from other goodies, that it'll be easy to integrate, as a developer, other WSGI apps into our app. 2) Making TG apps encapsulable as opaque WSGI apps that can be integrated into any bigger site. This means, user Joe could use our app easily in his site. 3) 1.1 apps that will look very similar to 1.0 apps to an application developer. So what's left for 2.0? Well, once we migrate TG's trunk to CP3 and make TG app's more WSGI friendly and composable it's time to start building TG's development tools using TG itself as a base. From my point of view, TG should concentrate on building development tools which allow for a Rapid Development Experience (wow, new buzzword ;) This is, CRUD generator, admin interface, model designer, etc...This means (not in chronological order): - CatWalk could be migrated/reimplemented into a TG 1.1 app, hopefully adding support for SA and being reusable in other frameworks/apps (as it would be a standalone WSGI app with a nice paste.app_factory entry point) and removed from TG's core. - ToscaWidgets can be introduced as TG would support it's preferred way of interfacing the framework, that is with a HostFramework object being initialized on every request by a piece of middleware. (If you ask, TW integrates into 1.0 without it's middleware...) - Identity could be replaced by two layers of middleware which handled authentication (AuthKit sounds like a nice candidate), and authorization (a refactored TurboPeakSecurity that is being gestated which will emulate Identity's authorization API but being generic functions in under the hood allowing any sort of crazy authorization policies) - Decorators can be simplified and made less magical/complex... I already have some ideas experiments for this... - We can start investigating/stealing useful tools from other projects.... (I18NToolbox, Pylons version of EvalException, HTTPEncode, etc, etc...) - ..... So, does this sound reasonable? Am I missing something? Opinions? Suggestions? Questions? Free beer? 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 -~----------~----~----~----~------~----~------~--~---
TGapp.pdf
Description: Adobe PDF document
