durusmail: qp: Re: qpy development ideas
qpy development ideas
2007-10-08
2007-10-09
Re: qpy development ideas
2007-10-10
2007-10-10
2007-10-14
2007-10-15
David K. Hess (2 parts)
2007-10-09
2007-10-09
2007-10-10
2007-10-10
2007-10-10
2007-10-10
2007-10-10
Re: qpy development ideas
David K. Hess
2007-10-17

On Oct 17, 2007, at 12:26 PM, David Binger wrote:
>
> On Oct 17, 2007, at 12:00 PM, Michael Watkins wrote:
>
>> Maybe now that ElementTree is part of standard Python, some
>> variation of your patch might make it into Publisher, or at least
>> into one of the QP or Dulcinea demo packages, depending on where in
>> the quantum placet continuum this ability falls.
>
> I think this is interesting, but I feel reluctant to add it
> to the QP distribution.
>
> I don't really see the need for decorators at all for this.
> It seems like all of this would be clearer if your SitePublisher
> simply overrides fill_response() call the inherited method, and
> then validate and/or revise the response body as desired.
> I assume different QP site authors might want different forms
> of validation, and different forms of output formatting.

Yeah, I'm not convinced this should be a part of qp/qpy either but I
do think it's a usage pattern that should be considered if not
accommodated.

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 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.

Dave

------
David K. Hess
Cell 214.684.5448 | Fax 214.764.7183
dhess@fishsoftware.com



reply