Re: zope.viewlet and zope.contentprovider - options for Zope 2 and Plone 3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.  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.
> 
>  - Are they scheduled to be in Zope 2.10?

Either that, or we make make them available as egg-enabled add-ons.  The
current effort is actually to move non-essential packages out of
'zope.app' and into more reusable "top-level" packages.  Most of those
packages should have clearly-defined dependencies, and therefore make
good candidates for eggification.  For progress to date, see:

  http://download.zope.org/distribution/

and my blog postings on the eggification process:


http://palladion.com/home/tseaver/obzervationz/2006/eggifying_zope_20060405


http://palladion.com/home/tseaver/obzervationz/2006/eggifying_zodb_20060406

> 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.
> 
>  - 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?

Andreas is still finishing this, but reports that he is very close.  I
would imagine that it will indeed land for 2.10:

  http://mail.zope.org/pipermail/zope-dev/2006-April/027280.html

> 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.
> 
> The tricky part is the ITALNamespaceData update magic that needs to
> read  the TAL context:
> 
>  - 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?
> 
>  - 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'm hoping none of the fakery will be required with Zope 2.10.

> 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.
> 
>  - Is this expected behaviour? Is it considered as "known issue"? Are 
> there plans to improve on this?

Dunno.


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          
tseaver-npLdOuuzvjyaMJb+Lgu22Q@xxxxxxxxxxxxxxxx
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEOcLp+gerLs4ltQ4RAgB2AKCUalPNb1Cer6bXeAmr+SISWHStGwCgq/f3
udEiKV3JlzXZadLDGZFZhjE=
=80pv
-----END PGP SIGNATURE-----