Paul Winkler wrote:
On Tue, Nov 29, 2005 at 09:34:09AM +0100, Paul Everitt wrote:
Hi all. I'd like to make a small proposal to enable investigation of a larger proposal.

I'm generally interested in the ideas of pipelines for markup rendering. Specifically, I'm interested in separating the concerns of skin scripters and corporate ID people into two logical parts:

Interesting stuff. One thing that immediately occurs to me:
""" 4) Opt-in. All templates in all core code and all add-on products have
to decipher the under-documented, un-enforced system of macros and slots
in order to leverage the corporate id work in main_template. If you want
to apply a consistent look and feel on all pages, you should be able to
impose it, whether the view template agreed or not
 3) Universal. The corporate id is not optional. It gets imposed on
every page in a site.

That goes too far IMO. Opt-in is a pain, but if you remove it, we need
to add an "opt-out" feature. Consider for example links that launch
pop-ups with some snippet of information in a smaller window. You
frequently want these to have a very stripped down look-and-feel. This
can be used for e.g. context help. I've seen a lot of sites like this
and worked on some.

That policy can be implemented in the tool itself. For this small proposal, the change wouldn't care. The tool could just return back the same then passed, unchanged. [wink]

This isn't revolutionary stuff. It's a meme that appears in Typo3 and a few Python templating systems.


At the EuroPython sprint, Tres coded up a nice little ZCML pipeline product that hooked Zope 3.1's publication events. However, this event isn't usable in Five 1.3.

Here's my small proposal for a near-term CMF 1.x release:

1) In CMFCore/, modify its pt_render or _exec.

2) Check to see if there is a configured pipeline tool.

3) If so, run the result of:

  result = self.pt_render(extra_context=bound_names)

...through the tool and return it.

So this wouldn't work for PageTemplate instances in the ZODB,
e.g. in portal_skins/custom/ ?

Ok, I picked the wrong spot for the proposed implementation. (I'm not a CMF guru, but I'd like to contribute.) Whatever implementation is chosen would need to cover both FS and customized template output.

Things I'm not proposing:

1) CMF out-of-the-box contains any tool nor any pipelines.

2) I'm not asking others to do the work on these. I'll learn enough to make some prototypes.

Before I write a proper proposal, though, I'd like to find out if there is basic interest:

1) Does the CMF have an interest in experimenting with ideas on splitting corporate ID responsibilities from product skin responsibilities?

To me, sure. Anything with the potential to reduce complexity of
main_template and increase cohesion is interesting :)

Incidentally, I'm intrigued that you latched onto the idea
of leveraging pure x(h)tml and just using the "id" attribute to identify
the boxes.  I don't mean to derail your thread, but I think we're
annoyed by some of the same misfeatures of the current big-complex-ZPT
approach in CMF, but we go in different directions with our ideas. Yours
is focused on leveraging and improving existing work with minimal pain,
mine is a bit more pie-in-the sky :)

Right. My proposal for the CMF change doesn't require XHTML. That's a policy for whatever tool gets installed and configured.

Also, even if you *did* choose what I would like to write, you could output as XHTML or HTML. :^)

In some recent discussions(1,2,3) about templating, I've grown
increasingly convinced that ZPT is too complex, and that I'd prefer
something along the lines of PyMeld(4).

Right, saw that and thought it was interesting.

Still, I'm hoping that my small, 3-line proposal doesn't get changed into a "let's replace templating systems" discussion. :^) I'm trying to find the smallest necessary part to cover the maximum interest.

Again to the CMF community: independent of this proposed solution, is this corporate ID a problem worth supporting investigation?


Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to