On Thu, Jan 13, 2011 at 5:22 AM, Joost Moesker <[email protected]> wrote: > I'm also interested in the patterns used by other developers to > section their application into distinct packages.
I have a Pylons application with several autonomous parts under a common auth mechanism. I wanted to split them up into packages or controller-routes-templates bundles but it was so difficult under Pylons I gave up. You can mount a WSGI app as a pseudo-controller, or have an action forward to one. The problem is how the Pylons environment is tightly integrated: - the magic globals - the 'full_stack' flag exists in middleware.py but nobody has mentioned using it, so I don't know how well a nested app + middleware would work in practical terms - there's only one place for templates in the application template, and no clear guidance on how to structure subapp templates, whether they should have a separate TemplateLookup, etc. - unclarity on whether you can have controllers in subdirectories. (You can but the 'controller' variable has to be slash delimited rather than dot delimited, but again there was little user feedback on how well this worked.) - what if you want to share 'app_globals' variables with the subapp, or conversely you want to prevent them from leaking to the subapp? This is a case where the much-maligned StackedObjectProxies are necessary, and would they be reliable? - What to do about INI settings for sub apps? - We don't have a local PyPI mirror so we can't easy_install local dependencies; we have to install them by hand from our Subversion repository. So a lot of separate packages is not necessarily a good thing in this environment. Some of these I have tentative answers to, but it was such an undocumented and underchartered territory that I didn't want to risk it in our most critical production app. So instead I put everything in one application, making a template subdirectory for each part, a separate controller (or three), and put all the routes together. > So how does pyramids help in this respect? One of Pylons 2's goals was to make it more friendly to nested apps; e.g., provide an alternative to the magic globals via instance variables in the controller. The BFG architecture is much more friendly to nested apps, which is one reason why it was chosen. There's also a cultural difference with Pyramid: a willing to deviate from application templates. There are fewer interdependencies between parts of the application, and those that exist are well-known containment patterns; i.e., attributes and keys. The "component architecture" is magic to some of us, but ordinary app developers don't have to see it, and we know it's running well in every other Pyramid app because those aren't breaking. Required middleware doesn't exist in Pyramid, and optional middleware is in the INI file rather than in a middleware.py. *mypyramidapp/__init__.py* is shorter and more straightforward than *mypylonsapp/config/*. 'app_globals' doesn't exist so all its complications disappear. All state data is under the 'request' object in straightforward attributes. Pyramid has documented ways of doing authentication, traversal lookup, and component piecing that Pylons never had. Etc. So all of these things mean Pyramid should work better with nested apps, but i don't know how well these ideas have been tested. The BFG developers among us may have more experience with nested apps. -- Mike Orr <[email protected]> -- 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.
