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

_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to