On Wed, 17 Oct 2007 14:03:23 -0500, "David K. Hess"
wrote:
> On that note, I would like to promote the use of decorators as a
> pattern with qp/qpy in general. The example I posted came from a
> modification to a "page" decorator I use. This decorator handles the
> ensure_signed_in, header and footer patterns without cluttering up
> the code in the exported method. What I've struggled with in qp is
> that each exported method is an entire page. Every method tends to
> carry ensure_signed_in, header and footer baggage - and header and
> footer carry page structure assumptions that are held for the entire
> application rather than just for that page. As David points out,
> fill_response is a good option for factoring out behavior but it also
> carries for the entire application rather than for sections of it.
I have not experimented with how using decorators would end up feeling and
looking like to separate the handling of many such shared issues. But I
suspect in this case decorators for such use may not be an ideal solution,
for two reasons:
Qp already defines a pattern, even if minimal, of declaring (read
decorating) some basic and common attributes for an exported page -- called
an "export" tuple in qp parlance. This declares the external url component,
the internal attribute, the crumb label, and the title for the page. Adding
generic decorators for handling things such as access control, templating,
etc, seem to me to be mixing two ways of doing the same thing. For me it
seems more natural to build on the export tuple pattern, adding to that
whatever attributes I'd like to have handled centrally for each exported
page. This is the path I explored in Gizmo(QP)... that adds a very simple
type, that I called an eXportable, and access control plus some other
things are declared there and handled entirely centrally. This allows to
have the all important access control logic in one place, and even if it is
quite evolved, you have a good chance of keeping it bug-free. This also
facilitated the addition of some permission options that I needed for some
applications, that otherwise I think would have been too messy to
implement... In the current svn trunk the eXportable object has also gained
arbitrary keyword args, that an application may declare and use as desired.
All this also retains total compatibility with the qp 4-tuple pattern.
Documentation about gizmo(qp) does not cover everything, but there is a
fairly good doc page for the extended and centralized permission handling,
at:
http://gizmojo.org/doc/permissions
In another application that I am evolving since some time now, these
eXportable objects are defined via an external data source, and doing this
has been completely natural, requiring no adjustments to the above way of
doing things. I suspect that decorators might have been also here somewhat
more cumbersome -- and in any case not adding anything particularly useful
when viewing the code, as the real condition is defined in a dynamic data
source elsewhere.
Plus, I think one decorator looks fine, two is also OK, but if one gets
into requiring to stack several for each exported page, hmmn, I always
found that somewhat unappealing.
> I believe decorators allow you to elegantly start splitting the user
> interface between a higher level page structure/behavior and some
> page specific content on a per page basis. I suppose another way of
> putting it is that this approach makes "skinning" of each page easier
> to achieve and isolates the behavior in one spot. You should be able
> to change the entire page structure (versus CSS look) of sections of
> a site by modifying decorators without touching any of the exported
> methods on the Directory objects.
I have achieved all this without decorators, and imho the source code for
each page is very clean. As for skinning, I approached that in a different
way... by building on the page() pattern of qp, and nothing else. The
page() is responsible for returning an entire and valid page, but the
caller only passes the essential info/data content for it to do so. The
handling of that i put into a Skin type, attached to the publisher. The
Skin is responsible for "templating" -- the calling exprted pages do not
even know whether the templating is being done by qpy of via another
engine.
I have a number of ideas for how to better streamline the current
implementation, after working with it so many months. Again, since 0.7
there are several improvements added in svn trunk... the old doc for
gizmo(qp)'s Skin and templating logic is at:
http://gizmojo.org/doc/skin/
mario
> Dave
>
> ------
> David K. Hess