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

[Jim Fulton]

Paul Everitt wrote:
> 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.

It is, at least, worth mentioning.  Te discussion is aimed at making
if feasible to provide post-processing within the server, although
it doesn't rule out out-of-server post processing.

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

I'm not sure what you are getting at here.

> 2) Regarding ordering of events for subscription,

Actually, ordering of subscriptions for events. :)

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

This is really apples and oranges.  The matching doen in XSLT is really
a search problem. You want to find the *best* match for a situation. This
is similar to normal component lookup, where you want to find the best-match
component.

Subscriptions are very different.  By definition, all subscribers are called.
Then the issue is what, if any ordering is needed.  It appears that a most-
general to most-specific ordering is useful, but other orderings are desireable
for other cases.  This happens to be an area where some good ideas are needed.
(See, for example, the recent discussion of ordering on ZODB-dev.)

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

I don't know what you mean.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org