The z3c.jbot package basically offers an easy way to provide template overrides much like zope 2 skins. It addresses the common issue with using a framework that already provides its own skin; you want to be able to easily customize it. In the current implementation, z3c.jbot monkeys its way into zope.pagetemplate to easily allow overriding the template source file. This is of course not optimal, but it works rather well. However, if we routinely switch between different file sources, performance will certainly suffer. This could happen if for instance a template override was registered only for a certain layer (not currently possible, but certainly desirable). At any rate, this could be fixed at the level of the page template implementation. Getting back to the monkey, perhaps it would make sense to formalize the way a template object gets its source file. The template class could adapt to an ``IFileSource`` implementation that would provide a filename. If there was such an entry point, other template implementations such as z3c.pt could also play along. But perhaps the whole idea is symptom treatment and there's no way forward. Comments welcome, especially in the light of PLIP #216 in which the z3c.jbot approach has been selected for inclusion in Plone*. *) http://plone.org/products/plone/roadmap/216 \malthe
On Jan 18, 2008, at 10:35 AM, Malthe Borch wrote:
In the current implementation, z3c.jbot monkeys its way into zope.pagetemplate to easily allow overriding the template source file.
Whacky.
certainly desirable). At any rate, this could be fixed at the level of the page template implementation.
Is this really a page template problem? It doesn't seem so. Why not make the separation cleaner? One pattern that we see hinted at in zope.formlib is that views (UI for the logic) reference templates that are registered elsewhere by name. The implementation there suffers in that the templates themselves aren't (so can't be selected based on the skin/layers), but if they're made to be named views of the (logic) view, all the flexibility you describe can be had. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com>
Fred Drake wrote:
On Jan 18, 2008, at 10:35 AM, Malthe Borch wrote:
In the current implementation, z3c.jbot monkeys its way into zope.pagetemplate to easily allow overriding the template source file.
Whacky.
Sure it's wacky; it's also the only straightforward way to customize Plone at the moment.
Is this really a page template problem? It doesn't seem so.
I'm not sure of it is, but certainly it's quite logically to want to take an existing template and change a bit, only you don't want to change the original package of course. Point being that the template itself is a very concrete object of interest and it's easy to understand how to customize it.
Why not make the separation cleaner? One pattern that we see hinted at in zope.formlib is that views (UI for the logic) reference templates that are registered elsewhere by name. The implementation there suffers in that the templates themselves aren't (so can't be selected based on the skin/layers), but if they're made to be named views of the (logic) view, all the flexibility you describe can be had.
Right certainly named templates is one way to do it. The approach I took was assigning canonical names based on the actual location on the file system and the package. I'm not saying it's the right approach, but it's certainly an approach that works well with packages that define skins using ViewPageTemplateFile-objects. \malthe
On Fri, Jan 18, 2008 at 04:35:58PM +0100, Malthe Borch wrote:
Getting back to the monkey, perhaps it would make sense to formalize the way a template object gets its source file. The template class could adapt to an ``IFileSource`` implementation that would provide a filename.
What about zope.pagetemplate.interfaces.IPageTemplate? Personally I like the way z3c.form.form.BaseForm approaches this: def render(self): '''See interfaces.IForm''' # render content template if self.template is None: template = zope.component.getMultiAdapter((self, self.request), IPageTemplate) return template(self) return self.template() That way the template is just a multi adapter. I've made a zcml directive that registers a template as just such a multi-adapter: <pagetemplate for=".view.SomeView .interfaces.IMyLayer" bindings="view request" template="templates/mytemplate.pt" /> "bindings" explicitly defines what names each of the adapted objects is available as in the template. Because sometimes I don't only have a context and request. The only problem is that IPageTemplate is a bit heavy as an interface, it would perhaps be nicer to have a parent interface that only defines a __call__ method. -- Brian Sutherland
On Jan 18, 2008, at 11:58 AM, Brian Sutherland wrote:
What about zope.pagetemplate.interfaces.IPageTemplate?
Good, because there are no new interfaces that way.
Personally I like the way z3c.form.form.BaseForm approaches this:
def render(self): '''See interfaces.IForm''' # render content template if self.template is None: template = zope.component.getMultiAdapter((self, self.request), IPageTemplate) return template(self) return self.template()
That almost supports the use case. Do the adaptation first, then use self.template if there's no adapter, and you're golden. If a view needs more than one template, it can use names to distinguish the cases. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com>
On Friday 18 January 2008, Fred Drake wrote:
That almost supports the use case. Do the adaptation first, then use self.template if there's no adapter, and you're golden.
That's what we are doing too. z3c.template is pretty much that. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
On Fri, Jan 18, 2008 at 12:57:33PM -0500, Stephan Richter wrote:
On Friday 18 January 2008, Fred Drake wrote:
That almost supports the use case. ?Do the adaptation first, then use ? self.template if there's no adapter, and you're golden.
That's what we are doing too. z3c.template is pretty much that.
Can I register a template for this lookup using z3c.template? getMultiAdapter((self.my_discriminating_object, self, self.request), interface=IPageTemplate) -- Brian Sutherland
Hi Brian
Betreff: Re: [Zope-dev] A z3c.jbot without a monkey
[...]
Can I register a template for this lookup using z3c.template?
getMultiAdapter((self.my_discriminating_object, self, self.request), interface=IPageTemplate)
No, because our template is only a part of the view and adapts this view. We normaly access only the view and not the context from a template. There is no option to adapt other discriminators. Regards Roger Ineichen
-- Brian Sutherland _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
participants (5)
-
Brian Sutherland -
Fred Drake -
Malthe Borch -
Roger Ineichen -
Stephan Richter