On May 2, 2007, at 11:33 AM, durumdara wrote: > Commonly these codes are initialize the handlers (pre-phase: check the > rights to the selected object (page), load session datas, set global > variables, initialize databases); or finalize the result (post-phase: > format it, set the type of the output, and force the main template on > it).
In Pylons, you'd want to probably set __before__ and __after__ blocks in your main controller (in lib/base.py). These will be called before the controllers action and afterwards. This is the common place to setup: - Global objects and database sessions Setting the type of output is handled differently depending on your output. For example, if you use jsonify it will set the proper content-type, and the XMLRPC controller will set the proper content type as well. Centralizing the output-type setting thus doesn't make much sense as different controllers really need to handle that. You can set __before__ and __after__ methods in individual controllers too, which is likely where you'll want to declare permissions required for individual actions or the whole controller. Session data is loaded the first time you actually use it, this avoids unnecessary filesystem hits until you actually use the session. > In the modpy in the one of the working modes I can write one handler > procedure: this procedure is makes the pre-phase, call the page > specific functions, and later get the result and force the main skin > (template) on it. This is handled by a layout that is inherited, depending on the template language you use. Myghty, Mako, and Genshi all support template inheritance which is where you would setup the main skin. > So I want to ask that how to register these procedures in pylons, or > how to avoid the repeating of some codes (like page level > "init(); .... ; done()", or same codes that initialize or finalize the > handlers - see the example 1.)? Essentially, as you're coming from Zope, the biggest hurdle will be clearing your mind of the "Zope way" to accomplish the task. A recent recipe on using the SOAP service for example: http://docs.pythonweb.org/display/pylonscookbook/Making+a+SOAP +Controller+with+Optio%27s+Soaplib And the doc on using MoinMoin under Pylons: http://docs.pythonweb.org/display/pylonscookbook/A+Pylons+controller +with+MoinMoin+as+a+WSGI+callable Both rely on the fact that you can just hook WSGI apps up under Pylons, and Pylons *does not* force output-types or apply other formatting to the output of the controller. So in Pylons, the tasks you previously put in one place, are split-up to sit closer to the actual work being done. - Authorization will commonly be done at the controller level unless you want to require some sort of permission across multiple controllers, in which case putting that check in the lib/base.py controller's __before__ would be prudent. The formatting is handled - Formatting and site skins are handled by the template engines - Global objects for a request can be setup in the controller, the action, or the BaseController that is inherited by all your controllers - Session data is loaded when first accessed - Database sessions are commonly created at the BaseController level for use where needed Hope that helps, of course Pylons doesn't force any of this on you. There's nothing forcing you to use the BaseController and inherit from it, you could design some other system entirely.... I'd recommend staying with this layout as it'll make it easier for other people familiar with Pylons to maintain your project as too much customization when not 'necessary' can create maintenance nightmares. Cheers, Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
