Thoughts on adding some form of viewlet/portlet to bfg-pages

[Tim Hoffman]

I have been thinking about how I might add some sort of viewlet
mechanism to bfg-pages.

Kapil had suggested that I look at zope.viewlet and
zope.contentprovider

On investigation I have noted several things about both of these
packages.

They both definately make sense and would address this requirement
however bfg-pages has been built on top of repoze.bfg rather than a
pure zope3 stack. (I do have a pure zope3 stack running on gae (had
to do lots of hacks to zope.security, basically gutted it, and made
significant changes to zope.proxy, this app is even using z3c.form)
if you want to see running it its at baon.appspot.com and it is a very
early incarnation of what has become bfg-pages.

Unfortunately because I have chosen to use repoze.bfg (it was way
easier to get running on app engine)
a few things stick out about zope.viewlets and zope.contentprovider
that become problematic.

1. Both packages introduce a couple of dependancies on additional zope
3 packages that aren't really used in repoze.bfg specifically
zope.security, zope.traversing, zope.publisher, zope.contentprovider
and zope.app.pagetemplate. I know from experience gutting
zope.security and zope.app.pagetemplate (it has a huge dependancy
list) is probably not practical given a repoze.bfg model. I think we
could leverage off some of the work in these packages if it is deemed
appropriate but a lot of work would be required. Also repoze.bfg has
its own publiser, traversal and location mechanisms and I am not sure
how well they will play together (this is something I have always
worried about repoze.bfg - especially not using zope.traversing)

2. They both packages are pretty complex with what it appears to be an
awful lot of registrations. Now I like zope.component and adapters
and utilities and use them all the time but the downside is ever
increasing startup time. Which I do think is a problem. (with my
early zope3 stack on app engine I used zope.deferredimport a lot to
improve startup times by delaying the importing of the whole editing
code, and I wish to revisit this with bfg-pages. I was able to halve
the app startup time if you are not editing, which is the majority of
the time ;-)

Using memcache works with content and rendered output but
unfortunatley isn't really useful for caching adapter registrations at
the moment, as every time you did a query/lookup you would have to
still go back to the module based register as you couldn't be sure
anything is in memcache, so dynamic lookups are harder to accelerate
so I am leaning more towards storing at least parts of a viewlet
registration in the datastore instead and memcaching that. This means
you minimize what you have to load up at startup time and you may not
need some of the registrations you would otherwise have to make in
zcml.

I am also a little concerned these packages are very complex and
therefore also potentially harder to get your/my head around ;-)

Anyway thats enough rambling anythoughts criticsm etc is very welcome.