[Zope3-dev] Re: RFC: Publication Post-Processing

[Paul Everitt]

Jim Fulton wrote:
> 
> At:
> 
>   
> http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PublicationPostProcessing 
> 
> 
> I've put doesn some thoughs for discussion on making the publication APIs
> more explicit and for supporting post processing tasks like adding
> standard look and feel or adding missing page components.

I've read through this a couple of times now.  First, thanks a bunch, 
Jim, for putting so much thought into it.

Couple of thoughts:

1) I don't know if it is or isn't in-scope to discuss page composition 
outside of Zope server.

Consider the headings under "Need for page-composition support", 
"Pipelines", "Transitive Adaptation", and the subset described under 
"Subscription".  It might be possible to also do these inside a WSGI 
Twisted in Zope 3.2, for example.  It might also be possible to do these 
in mod_python.

They all depend on whether "Publication Post-Processing" should be able 
to access content *beyond* what enters the publication process.

2) Regarding ordering of events for subscription, it reminds me of (my 
apologies for this) XSLT.  You can have multiple temlates matching on 
variations of the same "event", so to speak:

<xsl:template match="person">
<xsl:template match="person[@type='customer']">
<xsl:template match="person" mode="header">

The spec and decisions made by implementors govern which matches.  If I 
understand it correctly, they seem to have reached the opposite 
conclusion as you.  More specific matches first, more general doesn't 
get called.

I like the merits of your thinking, though: "It might be argued that 
invoking more general subscribers first is, in fact, a reasonable, as it 
allows specific subscribers to build on work done by more general 
subscribers."

3) I'd be interested to hear how testing could be woven into the 
adapation process you describe.  Meaning, ways to make statements about 
the structure of the things coming in and going out.

--Paul