[Zope3-dev] Re: RFC: Publication Post-Processing
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=[EMAIL PROTECTED]'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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: Publication Post-Processing
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=[EMAIL PROTECTED]'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:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: Publication Post-Processing
Am 16.09.2005 um 15:59 schrieb Jim Fulton: Paul Everitt wrote: Jim Fulton wrote: 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. We need a definition what we mean with pipelines. I understand them with a unix-background, where elements of a pipeline are working on the result of the earlier elements. This is data driven, so a pipeline element does only get the information in the data plus some parameters. Paul probably means the reaching back of the pipeline elements in the application-server context. For example are the pipeline elements be called by a controller, which additionally holds the context of the object in the application space. In contrast the elements could purly be data driven, working on xml- data and nothing else. This looks more defined and is probably be simpler, but I see and fear that then parameter stuff is encoded in the xml-data to steer some transformations later in the pipeline. __Janko ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Publication Post-Processing
Jim Fulton schrieb: 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. Hi, as a UI designer I would like to have a page Object (not the context object) that I can adapt to IPublicationResult. I would like contracts for HTML pages, e.g something like: class IHTMLPage(zope.interface.Interface): Provides information for a generic HTML Page title = '' description = '' class IZMIPage(IHTMLPage): Provides information for a basic ZMI page scripts = [] # ordererd List of IZMIScriptFiles styles = [] # ordered List of IZMIStylesheetFiles class_names = IZMICSSNames # class names mapping with standard keys id_names = IZMIIdNames # id names mapping with standard keys actions = [] # IZMIActions views = [] # IZMIViews # ... anything needed by a IZMIPageRenderer class IHTMLPageRenderer(IPublicationResult): def render(obj, request, html_page): Renders a HTML page class IZMIPageRenderer(IHTMLPageRenderer) def render(obj, request, zmi_page): Renders a ZMI page A renderer should be able to use any template language to do its job, e.g. ZPT, DTML, PHP, XSLT ... IMHO. Disclaimer: I guess the code above is garbage, this is just for discussion, I'm still learning the basics :) Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
