Re: Best practices for functional encapsulation
I'm also interested in the patterns used by other developers to section their application into distinct packages. Recently i have been working with drupal and magento, and I must say i really appreciate how these project separate functionality into packages. For a large project this really is a must have, not only for reuse but also maintainability and developer sanity. Keep it small, keep it simple. So how does pyramids help in this respect? I don't see how the object dispatch mechanism really makes a difference here (been there done that with cherrypy turbogears). The primary issues is how one wire's together the different api's. Eg. a mini-app requires a user model which has a permissions attribute. How does this mini-app publish this requirement? And how can I wire up an app that supplies this api up with this mini-app? Secondly, how can i hook up parts of one mini-app into an another app. For example, an e-commerce site might have 'productpage' showing product details. This would be part of the catalog app. Yet i would also like to show a mini/cart in the template. This mini-cart is part of the shoppingcart app. I don't want shoppingcart logic in my productpage controller, so how do i integrate these apps. Django´s signals seems an interesting solution yet also obscure. I got a gut feeling the problem can be simply solved with plain polymorphism and ducktyping. We don´t need to create a new dispatch mechanism, it´s already build into the language. Honestly, I have been fighting with these issues in various MVC frameworks for years and haven't found a satisfactory pattern. Currently i'm trying to grok how magento does this with the Zend framework. At the moment it still seems overly complex to me, to much configuration. But that might be naivety on my side. I´m really looking forward how other developers are handling this. On 10 jan, 08:37, Marius Gedminas mar...@gedmin.as wrote: ... I get the impression that the answer is want modular applications? Switch to Pyramid. ... -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: [pyramid] why zope.sqlalchemy?
On Wednesday, January 12, 2011, Chris McDonough chr...@plope.com wrote: On Wed, 2011-01-12 at 22:30 +0100, Eric Lemoine wrote: Hi In the SQLAlchemy + URL Dispatch Wiki tutorial zope.sqlalchemy and its ZopeTransactionExtension are used. The pyramid_routesalchemy Paste template also configures the application's Session with the ZopeTransactionExtension. Is this extension actually required? If not why do the tutorial and pyramid_routesalchemy make use of it? The intent is to provide a single point of commit responsibility, an automation of a commit for a successful request and a rollback for a request that causes an exception. The actual technology used to do that is not really really that important; it happens to be repoze.tm2 and ZopeTransactionExtension. If you want the double whammy of inconvenience of not having your changes committed for you and you want to write code that commits before the request is finished (perhaps too early, when the request isn't actually known to be successful), you can disable it. ;-) Ok thanks. I'm curious to know what the pyramid_sqla package uses. -- Eric Lemoine Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac, Cedex Tel : 00 33 4 79 44 44 96 Mail : eric.lemo...@camptocamp.com http://www.camptocamp.com -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: [pyramid] why zope.sqlalchemy?
It's pretty trivial to write a middleware that does: try: your_app(environ, start_response) commit() except: rollback() but the ZopeTransactionExtension tries to avoid issuing a COMMIT statement if you did not alter any ORM objects during the transaction, while this TM might issue a commit when you use the database session for any reason (including looking up the groups for the logged in user). If you let the transaction manager do all of the transaction management then the preponderance of your code doesn't have to care which middleware it is using. Daniel -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Pylons routing newbie question
Hi, I recently started to work with Pylons and I'm a little confused
about the routing settings that Pylons use. As far as I read, in order
to serve a certain page as default(eg when accessing localhost:5000 ),
one must add a routing rule in appName/config/routing.py. The code
should look something like
map.connect('/', controller='hello', action='index'). However, the
application I need to work on does not have this rule and yet when
accessing localhost:5000 I'm directed to a login page automatically.
So is there another way to achieve this? I'm really confused on how
the pages are served in the browser, as I am used to the look for
index.php/asp/etc rule that usually apply for most languages. If
someone would explain this to me I'd really appreciate it. Thanks a
lot.
--
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
Re: Pylons routing newbie question
The way it works is Pylons looks for a matching file using the
appName/public folder as the root using StaticURLParser middleware (ie:
'/css/styles.css' maps to appName/public/css/styles.css), if it finds a
matching file there, it serves that, if it doesn't, then it looks for a
matching rule in routing.py to find the appropriate controller/action to
fire.
So in the case of '/', StaticURLParser looks in 'appName/public' and finds
'index.html' there and serves it up, without ever looking at routing.py. In
order for the map.connect line you provided to ever even be fired, you'd
have to first remove or rename the index.html file in the public folder.
This might be helpful to you for further details:
http://pylonsbook.com/en/1.1/exploring-pylons.html#serving-a-pylons-application
On Thu, Jan 13, 2011 at 5:26 AM, tibi3384 vaduvoiut...@gmail.com wrote:
Hi, I recently started to work with Pylons and I'm a little confused
about the routing settings that Pylons use. As far as I read, in order
to serve a certain page as default(eg when accessing localhost:5000 ),
one must add a routing rule in appName/config/routing.py. The code
should look something like
map.connect('/', controller='hello', action='index'). However, the
application I need to work on does not have this rule and yet when
accessing localhost:5000 I'm directed to a login page automatically.
So is there another way to achieve this? I'm really confused on how
the pages are served in the browser, as I am used to the look for
index.php/asp/etc rule that usually apply for most languages. If
someone would explain this to me I'd really appreciate it. Thanks a
lot.
--
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.compylons-discuss%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
--
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
Integrating OpenID from scratch?
Is there an easy way to integrate OpenID from scratch without repoze or AuthKit? Thanks -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Best practices for functional encapsulation
On Thu, Jan 13, 2011 at 5:22 AM, Joost Moesker joostmoes...@gmail.com 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 sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Best practices for functional encapsulation
On Mon, Jan 10, 2011 at 11:24 AM, Daniel Holth dho...@gmail.com wrote: WSGI is not the right layer for composing applications. Most WSGI framework developers have come to the conclusion that middleware is not all it's cracked up to be. The WSGI protocol is clunky and you have to do weird things to share data between layers. Route middleware, session middleware, and database middleware were good experiments but they showed this is not the best place for those. With Pyramid's event system you can plug in code at the beginning and end of every request and at other times, which can perform tasks otherwise done by Pylons BaseController.__call__ or middleware. The developers tried for three or four years to streamline the WSGI protocol (WSGI 2) but could never get consensus, and now there's a realization that just turning away from WSGI may be better. Not to eliminate WSGI in its basic purpose (connecting to a Python webserver), but to use other protocols for other stuff: WebOb, Pyramid components, etc. -- Mike Orr sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Integrating OpenID from scratch?
On Jan 13, 2011, at 1:19 PM, Timmy Chan wrote: Is there an easy way to integrate OpenID from scratch without repoze or AuthKit? Thanks Yup, http://pypi.python.org/pypi/pyramid-openid/ That's for pyramid though. If you're using Pylons 1.0, you might want to look at velruse, which though it hasn't been 'released', is used by quite a few folks and does OpenID auth: http://packages.python.org/velruse/index.html 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 pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Best practices for functional encapsulation
On Thu, 2011-01-13 at 13:41 -0800, Mike Orr wrote: 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. It is Pyramidic to compose multiple external sources into the same configuration using config.include as documented (poorly) here: http://docs.pylonsproject.org/projects/pyramid/dev/narr/advconfig.html#including-configuration-from-external-sources Any number of includes can be done to compose an application; includes can even be done from within other includes. Any directives can be used in an include that can be used outside of one (such as add_view, scan, add_handler, add_renderer, etc). Pyramid has a conflict detection system that will throw an error if two included externals try to add the same configuration in a conflicting way (such as both externals trying to add a route using the same name, or both externals trying to add a view with the same set of predicates). It's awful tempting to call this set of features something that can be used to compose a system out of pluggable applications. But in reality, there are a number of problems with claiming this: - The terminology is strained. Pyramid really has no notion of a plurality of applications, just a way to compose configuration from multiple sources to create a single WSGI application. That WSGI application may gain behavior by including or disincluding configuration, but once it's all composed together, Pyramid doesn't really provide any machinery which can be used to demarcate the boundaries of one application (in the sense of configuration from an external that adds routes, views, etc) from another. - Pyramid doesn't provide enough rails to make it possible to integrate truly honest-to-god, download-an-app-from-a-random-place and-plug-it-in-to-create-a-system pluggable applications. Because Pyramid itself isn't opinionated (it doesn't mandate a particular kind of database, it offers multiple ways to map URLs to code, etc), it's unlikely that someone who creates something application-like will be able to casually redistribute it to J. Random Pyramid User and have it just work by asking him to config.include a function from the package. This is particularly true of very high level components such as blogs, wikis, twitter clones, commenting systems, etc. The integrator (the Pyramid developer who has downloaded a package advertised as a pluggable app) will almost certainly have made different choices about e.g. what type of persistence system he's using, and for the integrator to appease the requirements of the pluggable application, he may be required to set up a different database, make changes to his own code to prevent his application from shadowing the pluggable app (or vice versa), and any other number of arbitrary changes. For this reason, we claim that Pyramid has extensible applications, not pluggable applications. Any Pyramid application can be extended without forking it as long as its configuration statements have been composed into things that can be pulled in via config.include. It's also perfectly reasonable for a single developer or team to create a set of interoperating components which can be enabled or disabled by using config.include. That developer or team will be able to provide the rails (by way of making high-level choices about the technology used to create the project, so there won't be any issues with plugging all of the components together. The problem only rears its head when the components need to be distributed to *arbitrary* users. Note that Django has a similar problem with pluggable applications that need to work for arbitrary
Re: Pylons routing newbie question
Thanks for the clarification. Indeed that makes sense and I read about
the behavior in the Guide to Pylons book as well. However this seems
to complicate things even more for me, as the application does not
contain any public folder, nor an index file. Nowhere in the
application structure does any of these exist. And all the routings
rules are:
map.connect('/{controller}')
map.connect('/{controller}/{action}')
map.connect('/{controller}/{action}/{id}')
map.connect('/xml/{controller}.{action}')
None of which would actually explain the redirect. At this point, I'm
guessing that some sort of authentication might be responsible for the
automatic redirect, since after the login, i'm forwarded to a 404
page. Each time afterward when accessing localhost:5000 I get a 404.
So by default I think Pylons doesn't find nor public/index.html nor a
routing rule that would serve a page so it shows the 404 but somehow
redirects to login if not authenticated.
--
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
