Re: am I evil?
Hello, On Feb 27, 2011, at 10:40 PM, Chris Withers wrote: I'm writing a SQLAlchemy SessionExtension based on this pattern: http://www.sqlalchemy.org/trac/browser/examples/versioning/history_meta.py?rev=7253:3ef75b251d06#L171 So, in the listener, I want to record the user that made the change. How should I get hold of the currently authenticated user? Maybe, you should consider another approach to this problem? I don't think that recipe you've mentioned is a good way of versioning content. I like more explicit approach here -- versioning logic be in application logic, but not inside persistence engine: some_obj = some_objects.get(123) user = request.user # mutate some_obj some_objects.store_revision(some_obj, user) -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: am I evil?
The event_manager could be ZCA event API. You could also move event-firing logic inside subclass of class of some_objects repository: Oh, sorry, I was thought of wrapping repository inside versioning repository proxy, not subclassing. :-) -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: pyramid_beaker vs beaker wsgi middleware
Hello Tres, FWIW, repoze.who 2.0 explicitly works to enable / ease using the machinery where needed in the app by exposing the configured plugins via an API (the login and logout views are the obvious consumers). It also retainis the flexibility of middleware for enforcing policies. sorry for some kind of off-topic, but what's the status on repoze.who 2.0? It seems a great piece of software, but why it's still in alpha stage? -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Some notes on Configurator.add_directive
Hello, I've just noticed[1] the adding of 'add_directive' method to 'Configurator' which is allow to extend it with configuration methods. But I have some questions: 1. Isn't this way is not very documentable? I mean, how would framework extenders document methods, they've added to 'Configurator'? For example, another solution to this problem is to compose application configurator from pyramid.config.Configurator mixed with some other extension classes (Mix-in pattern) -- this way extension methods are documented in their respectable mix-ins in usual way. See how I've done in in contentlet[2]. 2. I'm afraid this way does not respect ZCML mechanism of configuration, so developers should bother both of adding methods to configurator and also of adding corresponding ZCML directives. How about using some kind of reflection to generate ZCML directives for new methods -- this way we can keep both configuration API in sync? [1]: https://github.com/Pylons/pyramid/commit/659d5f6b1f7605daaa0666fab7061bba9848d241 [2]: http://packages.python.org/contentlet/#imperative-configuration -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: pyramid terminology: model-resource
Hello, On Fri, Dec 17, 2010 at 7:57 AM, Mark Ramm mark.mchristen...@gmail.com wrote: I think resource is a good term for items in the graph. Why you think resources are need to be bound to locations in graph? I think it's better to think that graph consist of locations and each location has associated resource. For example one can make one resource available via different URLs (read locations) with different views. -- Andrey Popp phone: +7 911 740 24 91 e-mail: 8may...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: pyramid terminology: model-resource
Hello, On Wed, Dec 15, 2010 at 8:13 PM, Chris McDonough chr...@plope.com wrote: I'm considering making a fairly major terminology change to the Pyramid docs. I'd like to consider renaming the term model to resource in the docs. I think resource term isn't suitable for this kind of thing, as being pointed already resource it's more like static resource (imgs, js, css, uploaded date). How about term location? I think it's more suitable: 1) In current terms model should implement ILocation interface, so it's location already and this is the only requirement that object should satisfy to take part in graph traversal, isn't it? 2) If we rename models to locations the process of context finding would have meaning of mapping from web locations (URIs) to application domain's locations. 3) Scala web framework Lift (the most popular Scala web framework) also has the notion of location and while it's not implemented with traversal but rather with mapping by user-specified function that make URL rewriting, I think term location is more suitable here — we can construct sitemaps, breadcumbs from location graph, also location sensitive permission model is more suitable for web apps, because views rare work with just one model at time. 4) Existence of repoze.bfg.traversalwrapper and repoze.bfg.traversaladapter (which are provides good patterns I think) also has no relation nor to resource, nor to model, but can provide good examples as mapping from application locations to domain models. -- Andrey Popp phone: +7 911 740 24 91 e-mail: 8may...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Twophase branch merged to Pyramid master.
Hello,
it's looking just great!
How do you think, can this behavior be extracted into some pattern for
imperative configuration? I would like to have this in my toolchain in addition
to zope.configuration.
--
Andrey Popp
On Thursday, December 9, 2010 at 11:19 AM, Chris McDonough wrote:
Hi all,
I just merged a branch I've been working on for some time to the Pyramid
master branch on Github. The branch was named twophase, and its goal
was to provide imperative configuration extensibility and two-phase
configuration much like that currently offered by ZCML.
As a result, the ``pyramid.configuration`` module has been deprecated
and exists now only to support backwards compatibility. In its place a
new ``pyramid.config`` module exists with fundamentally the same API.
Paster template authors beware.
What does this change get us? Imperative extensibility was the primary
goal (the ability to write extensible applications by including
configuration from other non-local sources). This was always a feature
offered to us by ZCML, but now folks don't have to use ZCML to get it.
Here's an example of using imperative configuration to include
configuration from a non-local source. If the ``configure`` function
below lives in a module named ``myapp.myconfig``:
# myapp.myconfig module
def my_view(request):
from pyramid.response import Response
return Response('OK')
def configure(config):
config.add_view(my_view)
You might cause it be included within your Pyramid application like so:
from pyramid.config import Configurator
def main(global_config, **settings):
config = Configurator()
config.include('myapp.myconfig.configure')
return config.make_wsgi_app()
When application extensibility of this kind is used, often configuration
conflicts are an issue. When you reuse some configuration from another
module, it's more likely that the configuration in that module will
conflict with configuration statements you execute locally or other
configuration statements executed as the result of including some other
configuration. For this reason, *configuration conflict detection* is
now a feature by default.
Included configuration statements will be overridden by local
configuration statements if an included callable causes a configuration
conflict by registering something with the same configuration
parameters. So for instance, in the below, the local add_view call
will win even though both views are registered for the same thing:
from pyramid.config import Configurator
def someview(request):
from pyramid.response import Response
return Response('OK')
def main(global_config, **settings):
config = Configurator()
config.add_view(someview)
config.include('myapp.myconfig.configure')
return config.make_wsgi_app()
However, if two *included* configuration callables register the same
configuration parameters, a ConfigurationConflictError will now occur.
For example:
# myapp.myconfig module
def my_view(request):
from pyramid.response import Response
return Response('OK')
def configure(config):
config.add_view(my_view)
# myapp.myconfig2 module
def my_view(request):
from pyramid.response import Response
return Response('OK')
def configure(config):
config.add_view(my_view)
# your application's __init__
from pyramid.config import Configurator
def main(global_config, **settings):
config = Configurator()
config.include('myapp.myconfig.configure')
config.include('myapp.myconfig2.configure')
return config.make_wsgi_app()
When ``make_wsgi_app`` is called, the configuration will be committed,
and a conflict will be detected, because both myapp.myconfig.configure
and myapp.myconfig2.configure registered a view with the same
configuration parameters. To avoid a conflict, and make
myapp.myconfig2.configure win, you can call commit between the
calls to include:
# your application's __init__
from pyramid.config import Configurator
def main(global_config, **settings):
config = Configurator()
config.include('myapp.myconfig.configure')
config.commit()
config.include('myapp.myconfig2.configure')
return config.make_wsgi_app()
Calling commit executes all pending configuration and clears the
configuration stack. It is safe to call commit() at any time.
make_wsgi_app calls commit on your behalf usually, but you can issue
commits at any time.
A conflict error will now occur if you register two configuration
statements for the same set of arguments locally too:
from pyramid.config import Configurator
def someview(request):
from pyramid.response import Response
return Response('OK')
def someotherview(request):
from pyramid.response import Response
return Response('OK')
def main(global_config, **settings):
config = Configurator()
config.add_view(someview)
config.add_view(someotherview)
return config.make_wsgi_app()
Because both
Re: Pyramid 1.0a4 released
Hello, On Sun, Nov 21, 2010 at 9:00 AM, Chris McDonough chr...@plope.com wrote: - Add a ``pyramid.url.route_path`` API, allowing folks to generate relative URLs. Calling ``route_path`` is the same as calling ``pyramid.url.route_url`` with the argument ``_app_url`` equal to the empty string. How about to re expose ``pyramid.traversal.model_path`` as ``pyramid.url.model_path``? I think it is less confusing to find out all URL generation functions in one scope, isn't it? -- Andrey Popp phone: +7 911 740 24 91 e-mail: 8may...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
