[Zope3-Users] zope.viewlet and zope.contentprovider - options for Zope 2 and Plone 3

[Stephan Richter]

On Sunday 09 April 2006 16:25, Martin Aspeli wrote:
> Hi guys (sorry for the crosspost, this is rather a cross-area post),
>
> I'm reading the docs for zope.contentprovider and zope.viewlet, and there
> are many reasons why we'd like to use this in Plone. The way the release
> cycles work, Plone 3.0 would be the natural place to put some of this.

Yes, I think a big application/CMS like Plone would vastly benefit from this 
approach. It also severs as a great base to implement JSR-168-like portlets. 
I have started doing some of this work by storing the display state of 
viewlet and having a URL for each viewlet:

http://svn.zope.org/zope.webdev/trunk/browser/pagelet.py?rev=41494&view=auto

Note much tested but it shows a state and namespace implementation. Teh reason 
I have not started imlementing a full-fledged portlet implementation is 
because I am too lazy to read and comprehend JSR 168.

> Now, I have a few questions:
>
>   - In what version of Zope 3 did zope.contentprovider and zope.viewlet
> appear? They're not in my Zope 2.9 lib/python/zope.

Zope 3.2. They really *should* be in Zope 2.9. This is a feature bug.

>   - Are they scheduled to be in Zope 2.10?

At least! Zope 2 people, could you make sure that zope.contentprovider and 
zope.viewlet are dependencies of the release?

> The main achilles heel as far as I can tell is the TALES 'provider:'
> expression. I'm guessing that without using the Zope 3 ZPT and TALES
> implementations, Zope 2 won't be able to use these.

I don't think so. The TALES expressions engines in Zope 2 and 3 share the same 
API. So all you need to do is to generate a custom engine. If the Five 
developers port the tales:expressiontype directive, then you can actually 
just use the code as is. ;-)

>   - Is it the intention to use the Zope 3 ZPT and TALES engines in Zope
> 2.10? If not, are they scheduled for some other time? How much work is
> needed for this to be a reality?

You'll have to ask Andreas how far his work is.

> Now, I have a feeling that this could be faked in Zope 2 with something
> like:
>
> 	<tal:block replace="structure python:provider('provider.name')" />
>
> the object 'provider' would have to be defined globally (in
> global_defines.pt in Plone). Its implementation would basically be
> identical to the TALESProviderExpression in zope.contentprovider, with a
> __call__() method that called update() and render() on an IContentProvider
> looked up by the name it was passed.

Let's try to find a non-hacky solution. ;-) I think it will work the right way 
too.

> The tricky part is the ITALNamespaceData update magic that needs to read
> the TAL context:

Ah ok. But I think the worst case scenario would be to reimplement the TALES 
namespace expression code. It's just a few lines.

>   - Is there some way a python object referred in an expression like the
> one above could be passed or acquire (literally or figuratively) TAL
> objects defined in the current context at that point?

Yes, I think this is possible; But Zope 2 should also have an econtext.

>   - If not, based on your practical experience, how much is this used -
> would zope.contentprovider and zope.viewlet be useless if Plone had to say
> "we only support a subset of the zope.contentprovider API" (note: we
> really don't want to do that, I'm just looking at options here)

I think we will not have to worry about this case.

> The other problem with this implementation is that it would call
> viewlets/content providers sequentially, i.e. call update(), then render()
> for each object as it discovered them, not call all the update()'s and
> then all the render()'s. I note that the zope.contentprovider README.txt
> mentions that this is bad, but the TALESProviderExpression implementation
> seems to suffer from exactly the same problem.

Right, but this is a non-issue for you because noone in the Plone world is 
using 2-phase rendering at this stage. Only zope.formlib, 
zope.contentprovider and zope.viewlet support the 2-phase rendering API at 
this point.

>   - Is this expected behaviour?

Yes.

>   Is it considered as "known issue"?

I would call it a known limitation, others call it the "render bug".

>   Are there plans to improve on this?

You can only improve on this by making all views/pagetemplates implement 
2-phase rendering.

For the uninitiated: 2-phase commit means that first an update() method is 
called on all components involved in presentation (pages, forms, widgets, 
content providers, viewlets) and then the actual render() is called to 
retrieve the actual output.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training