Re: [Repoze-dev] page directive sci-fi
On Sep 13, 2009, at 1:59 PM, Chris Rossi wrote: This looks reasonable. I think it would also be reasonable to just make this the standard 'view' functionality, since afaict the current functionality is a subset of this. +1 for adding the attributes/functionality below as options to the current view directive. ~ro Chris On Sun, Sep 13, 2009 at 12:57 PM, Chris McDonough chr...@plope.com wrote: Here's some sci fi I wrote up about a page ZCML directive. As Tim Hoffman suggested, maybe the fact that the page is passed into the template would give us enough pull capability to avoid any of the other hacks I proposed to push global names into every rendered template. Note that the view directive could probably eventually be changed to do everything that the page directive I describe below does. Comments appreciated. repoze.bfg.page README == ``repoze.bfg.page`` is a package which adds a ``page`` ZCML directive to the set of directives that may be used under BFG. You might use a ``page`` directive in places where you would otherwise use the built-in repoze.bfg ``view`` directive. Defining a ``page`` directive effectively creates a single BFG view under the hood, and owns attributes similar to those of a view directive. However, the ``page`` directive differs from the BFG ``view`` directive in a number of important ways: - The ``page`` directive allows you to associate a *template* with the page being defined. The machinery behind the ``page`` directive is capable of rendering an associated template, unlike a view, which must find and render a template itself. - A ``page`` directive, like a BFG ``view`` directive, points at a callable which accepts two arguments: ``context`` and ``request``. This callable must return a Response object *or* a Python dictionary. This is unlike a BFG ``view`` callable, which always returns a Response object (and must never return a dictionary). The ``callable`` which a ``page`` directive points at may optionally be a class. If the page directive's ``callable`` attribute points at a class, that class must have an ``__init__`` method that accepts two arguments: ``context`` and ``request``. That class must further define a ``__call__`` method which accepts no arguments and which returns a dictionary or a Response object. If the page callable returns a Python dictionary, the ``template`` named within the directive will be passed the dictionary as its keyword arguments, and the ``page`` implementation will return the resulting rendered template in a response to the user. The callable object (whatever object was used to define the page ``callable``) will be automatically inserted into the set of keyword arguments passed to the template as ``page``. If the callable object was a class, an instance of that class will be inserted into the keyword arguments as ``page``. If the ``callable`` associated with a ``page`` directive returns a Response object (an object with the attributes ``status``, ``headerlist`` and ``app_iter``), any template associated with the ``page`` declaration is ignored, and the response is passed back to BFG. For example, if your page callable returns an ``HTTPFound`` response, no template rendering will be performed:: from webob.exc import HTTPFound return HTTPFound(location='http://example.com') # templating avoided Here's an example of a page directive which acts as a default view:: page template=templates/my_template.pt callable=.pages.my_page / The ``template`` attribute is optional. If one is not named, and the callable returns a dictionary, an error will be thrown at rendering time. Special ZCML Attributes --- The directive accepts attributes other than ``template`` and ``callable``. attr ``repoze.bfg.page`` defaults to using the ``__call__`` method of the page callable to obtain a response dictionary. The ``attr`` value allows you to vary that method name. For example, if your class had a method named ``index`` and you wanted to use this method instead of ``__call__``, you'd say ``attr=index`` in the page ZCML definition. This is most useful when the page definition is a class. for A Python dotted-path name representing the Python class that the :term:`context` must be an instance of, *or* the :term:`interface` that the :term:`context` must provide in order for this view to be found and called. name The *view name*. Read and understand :ref:`traversal_chapter` to understand the concept of a view name. permission The name of a *permission* that the user must possess in order to call the view. See :ref:`view_security_section` for more information about view security and permissions. request_method This value can either be one of the strings 'GET', 'POST', 'PUT',
[Repoze-dev] page directive sci-fi
Here's some sci fi I wrote up about a page ZCML directive. As Tim Hoffman suggested, maybe the fact that the page is passed into the template would give us enough pull capability to avoid any of the other hacks I proposed to push global names into every rendered template. Note that the view directive could probably eventually be changed to do everything that the page directive I describe below does. Comments appreciated. repoze.bfg.page README == ``repoze.bfg.page`` is a package which adds a ``page`` ZCML directive to the set of directives that may be used under BFG. You might use a ``page`` directive in places where you would otherwise use the built-in repoze.bfg ``view`` directive. Defining a ``page`` directive effectively creates a single BFG view under the hood, and owns attributes similar to those of a view directive. However, the ``page`` directive differs from the BFG ``view`` directive in a number of important ways: - The ``page`` directive allows you to associate a *template* with the page being defined. The machinery behind the ``page`` directive is capable of rendering an associated template, unlike a view, which must find and render a template itself. - A ``page`` directive, like a BFG ``view`` directive, points at a callable which accepts two arguments: ``context`` and ``request``. This callable must return a Response object *or* a Python dictionary. This is unlike a BFG ``view`` callable, which always returns a Response object (and must never return a dictionary). The ``callable`` which a ``page`` directive points at may optionally be a class. If the page directive's ``callable`` attribute points at a class, that class must have an ``__init__`` method that accepts two arguments: ``context`` and ``request``. That class must further define a ``__call__`` method which accepts no arguments and which returns a dictionary or a Response object. If the page callable returns a Python dictionary, the ``template`` named within the directive will be passed the dictionary as its keyword arguments, and the ``page`` implementation will return the resulting rendered template in a response to the user. The callable object (whatever object was used to define the page ``callable``) will be automatically inserted into the set of keyword arguments passed to the template as ``page``. If the callable object was a class, an instance of that class will be inserted into the keyword arguments as ``page``. If the ``callable`` associated with a ``page`` directive returns a Response object (an object with the attributes ``status``, ``headerlist`` and ``app_iter``), any template associated with the ``page`` declaration is ignored, and the response is passed back to BFG. For example, if your page callable returns an ``HTTPFound`` response, no template rendering will be performed:: from webob.exc import HTTPFound return HTTPFound(location='http://example.com') # templating avoided Here's an example of a page directive which acts as a default view:: page template=templates/my_template.pt callable=.pages.my_page / The ``template`` attribute is optional. If one is not named, and the callable returns a dictionary, an error will be thrown at rendering time. Special ZCML Attributes --- The directive accepts attributes other than ``template`` and ``callable``. attr ``repoze.bfg.page`` defaults to using the ``__call__`` method of the page callable to obtain a response dictionary. The ``attr`` value allows you to vary that method name. For example, if your class had a method named ``index`` and you wanted to use this method instead of ``__call__``, you'd say ``attr=index`` in the page ZCML definition. This is most useful when the page definition is a class. for A Python dotted-path name representing the Python class that the :term:`context` must be an instance of, *or* the :term:`interface` that the :term:`context` must provide in order for this view to be found and called. name The *view name*. Read and understand :ref:`traversal_chapter` to understand the concept of a view name. permission The name of a *permission* that the user must possess in order to call the view. See :ref:`view_security_section` for more information about view security and permissions. request_method This value can either be one of the strings 'GET', 'POST', 'PUT', 'DELETE', or 'HEAD' representing an HTTP ``REQUEST_METHOD``. A view declaration with this attribute ensures that the view will only be called when the request's ``method`` (aka ``REQUEST_METHOD``) string matches the supplied value. request_param This value can be any string. A view declaration with this attribute ensures that the view will only be called when the request has a key in the ``request.params`` dictionary (an HTTP
Re: [Repoze-dev] page directive sci-fi
I may be missing something that makes this impossible, but my point was that you could probably add it to the existing implementation without changing how any existing applications work. The existing functionality is all there as a subset of the new stuff. But I haven't stared at it for too long so I may be missing obvious backwards incompatibility. Chris On Sun, Sep 13, 2009 at 10:29 PM, Tim Hoffman t...@zute.net wrote: Hi I am not too sure about making this the default 'view' implementation or at least we need to retain the existing the simpler view directive. I many cases I am/need to identify the template used much later in the process, so for me baking the template name in the view directive is certainly not what I want T On Mon, Sep 14, 2009 at 1:59 AM, Chris Rossi ch...@archimedeanco.com wrote: This looks reasonable. I think it would also be reasonable to just make this the standard 'view' functionality, since afaict the current functionality is a subset of this. Chris On Sun, Sep 13, 2009 at 12:57 PM, Chris McDonough chr...@plope.com wrote: Here's some sci fi I wrote up about a page ZCML directive. As Tim Hoffman suggested, maybe the fact that the page is passed into the template would give us enough pull capability to avoid any of the other hacks I proposed to push global names into every rendered template. Note that the view directive could probably eventually be changed to do everything that the page directive I describe below does. Comments appreciated. repoze.bfg.page README == ``repoze.bfg.page`` is a package which adds a ``page`` ZCML directive to the set of directives that may be used under BFG. You might use a ``page`` directive in places where you would otherwise use the built-in repoze.bfg ``view`` directive. Defining a ``page`` directive effectively creates a single BFG view under the hood, and owns attributes similar to those of a view directive. However, the ``page`` directive differs from the BFG ``view`` directive in a number of important ways: - The ``page`` directive allows you to associate a *template* with the page being defined. The machinery behind the ``page`` directive is capable of rendering an associated template, unlike a view, which must find and render a template itself. - A ``page`` directive, like a BFG ``view`` directive, points at a callable which accepts two arguments: ``context`` and ``request``. This callable must return a Response object *or* a Python dictionary. This is unlike a BFG ``view`` callable, which always returns a Response object (and must never return a dictionary). The ``callable`` which a ``page`` directive points at may optionally be a class. If the page directive's ``callable`` attribute points at a class, that class must have an ``__init__`` method that accepts two arguments: ``context`` and ``request``. That class must further define a ``__call__`` method which accepts no arguments and which returns a dictionary or a Response object. If the page callable returns a Python dictionary, the ``template`` named within the directive will be passed the dictionary as its keyword arguments, and the ``page`` implementation will return the resulting rendered template in a response to the user. The callable object (whatever object was used to define the page ``callable``) will be automatically inserted into the set of keyword arguments passed to the template as ``page``. If the callable object was a class, an instance of that class will be inserted into the keyword arguments as ``page``. If the ``callable`` associated with a ``page`` directive returns a Response object (an object with the attributes ``status``, ``headerlist`` and ``app_iter``), any template associated with the ``page`` declaration is ignored, and the response is passed back to BFG. For example, if your page callable returns an ``HTTPFound`` response, no template rendering will be performed:: from webob.exc import HTTPFound return HTTPFound(location='http://example.com') # templating avoided Here's an example of a page directive which acts as a default view:: page template=templates/my_template.pt callable=.pages.my_page / The ``template`` attribute is optional. If one is not named, and the callable returns a dictionary, an error will be thrown at rendering time. Special ZCML Attributes --- The directive accepts attributes other than ``template`` and ``callable``. attr ``repoze.bfg.page`` defaults to using the ``__call__`` method of the page callable to obtain a response dictionary. The ``attr`` value allows you to vary that method name. For example, if your class had a method named ``index`` and you wanted to use this method instead of
Re: [Repoze-dev] page directive sci-fi
Hi Chris You are correct, I just didn't want to see the view directive just disappear and be left with a page implementation ;-). T On Mon, Sep 14, 2009 at 10:34 AM, Chris Rossi ch...@archimedeanco.com wrote: I may be missing something that makes this impossible, but my point was that you could probably add it to the existing implementation without changing how any existing applications work. The existing functionality is all there as a subset of the new stuff. But I haven't stared at it for too long so I may be missing obvious backwards incompatibility. Chris On Sun, Sep 13, 2009 at 10:29 PM, Tim Hoffman t...@zute.net wrote: Hi I am not too sure about making this the default 'view' implementation or at least we need to retain the existing the simpler view directive. I many cases I am/need to identify the template used much later in the process, so for me baking the template name in the view directive is certainly not what I want T On Mon, Sep 14, 2009 at 1:59 AM, Chris Rossi ch...@archimedeanco.com wrote: This looks reasonable. I think it would also be reasonable to just make this the standard 'view' functionality, since afaict the current functionality is a subset of this. Chris On Sun, Sep 13, 2009 at 12:57 PM, Chris McDonough chr...@plope.com wrote: Here's some sci fi I wrote up about a page ZCML directive. As Tim Hoffman suggested, maybe the fact that the page is passed into the template would give us enough pull capability to avoid any of the other hacks I proposed to push global names into every rendered template. Note that the view directive could probably eventually be changed to do everything that the page directive I describe below does. Comments appreciated. repoze.bfg.page README == ``repoze.bfg.page`` is a package which adds a ``page`` ZCML directive to the set of directives that may be used under BFG. You might use a ``page`` directive in places where you would otherwise use the built-in repoze.bfg ``view`` directive. Defining a ``page`` directive effectively creates a single BFG view under the hood, and owns attributes similar to those of a view directive. However, the ``page`` directive differs from the BFG ``view`` directive in a number of important ways: - The ``page`` directive allows you to associate a *template* with the page being defined. The machinery behind the ``page`` directive is capable of rendering an associated template, unlike a view, which must find and render a template itself. - A ``page`` directive, like a BFG ``view`` directive, points at a callable which accepts two arguments: ``context`` and ``request``. This callable must return a Response object *or* a Python dictionary. This is unlike a BFG ``view`` callable, which always returns a Response object (and must never return a dictionary). The ``callable`` which a ``page`` directive points at may optionally be a class. If the page directive's ``callable`` attribute points at a class, that class must have an ``__init__`` method that accepts two arguments: ``context`` and ``request``. That class must further define a ``__call__`` method which accepts no arguments and which returns a dictionary or a Response object. If the page callable returns a Python dictionary, the ``template`` named within the directive will be passed the dictionary as its keyword arguments, and the ``page`` implementation will return the resulting rendered template in a response to the user. The callable object (whatever object was used to define the page ``callable``) will be automatically inserted into the set of keyword arguments passed to the template as ``page``. If the callable object was a class, an instance of that class will be inserted into the keyword arguments as ``page``. If the ``callable`` associated with a ``page`` directive returns a Response object (an object with the attributes ``status``, ``headerlist`` and ``app_iter``), any template associated with the ``page`` declaration is ignored, and the response is passed back to BFG. For example, if your page callable returns an ``HTTPFound`` response, no template rendering will be performed:: from webob.exc import HTTPFound return HTTPFound(location='http://example.com') # templating avoided Here's an example of a page directive which acts as a default view:: page template=templates/my_template.pt callable=.pages.my_page / The ``template`` attribute is optional. If one is not named, and the callable returns a dictionary, an error will be thrown at rendering time. Special ZCML Attributes --- The directive accepts attributes other than ``template`` and ``callable``. attr ``repoze.bfg.page`` defaults to using the ``__call__`` method of the
Re: [Repoze-dev] page directive sci-fi
Tim Hoffman wrote: Hi Chris You are correct, I just didn't want to see the view directive just disappear and be left with a page implementation ;-). I just baked all this behavior into the view directive on the trunk. There are no backwards incompatibilities. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
