[Zope3-dev] RFC: Publication Post-Processing

[Craeg Strong]

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.

Unfortunately I don't yet have any comments to offer on architecture or 
design, as I am only half-way through Philipp's most excellent Zope3 book.

However, I do have a couple of requirements-scenarios that might help. 

(1) Include docbook documents inside a zope3-based website.

Like many consultancies, we like to include whitepapers, articles, etc. 
on our website.
We happen to use docbook for our markup.  Fortunately, docbook comes 
with XSLT scripts that automatically render the content to HTML or PDF.

- we want to use the docbook XSLT out of the box without having to 
change it (much)
- we want the rendered HTML surrounded by our custom header, footer, 
left navigation menu, etc.
- we want to use intelligent caching so that we don't waste processing 
cycles re-running the XSLT if the content hasn't changed
- we want the XSLT to be re-run when we make (fairly frequent) changes
- note the header/footer/nav menu might be different for different roles 
(e.g. "edit" button for authorized users)

(2) support modular rendering of screens in a zope3-based web application

We are building a web application that is highly dynamic and configurable. 
Users in different departments will login and see different headers, 
footers, and nav menus.
Users in different roles will have access to different functionality, or 
different versions of screens.

The workflow is customized per role and per department.  For example 
managers don't require 2nd level approvals.
Different departments might require approvals from different roles (HR, 
for example).

Our screens use AJAX technology, with several capabilities accessible 
from a single view, so
a single permission is not sufficient-- a view might provide access to a 
dozen different permissioned capabilities.
We also need to filter data-- for example a search result for a manager 
must only include those employees he has rights to see.

The application features a set of configuration screens so that 
authorized users can change the workflow, role-permissions,
certain reference data (e.g. available leave types), and schema (whether 
certain fields are required, etc.).

The way we have implemented this (in a previous Java incarnation) is by 
creating a set of modular XSLT scripts that are applied in a pipeline.

- stage one might fill in the headers and footers.  They are cached on a 
_per session_ basis, since they are unique to a login session
- stage two might fill in the navigation bar; it is cached for everyone 
in the same role and department.
- stage three might filter the view based on the user's authorizations 
and workflow info for the context object
- stage four might finish the rendering

Scenario #2 could probably be done using ZPT rather than XSLT, but the 
advantage of XSLT is its ubiquity. 
Also, by using XSLT we enforce separation of concerns-- our business 
objects emit data and metadata in XML, and that is the only thing the 
controller deals with.

I am not sure if these scenarios are on target or not.  

However, I would like to volunteer to help test out/flesh out an 
implementation that might be applied in one or both of the above.

Regards,

--Craeg