[Zope3-dev] Content space persistent modules

[Leonardo Rochael Almeida]

For the longest time, I've been reading zope3-dev in digest-mode
because I was way behind in my e-mail overall.

While catching up, I've read the *scripters vs developers* thread with
great interest.

I happen to like PythonScripts, but I understand Jim's feelings that
they're a kludge, not being full python files and all. I also happen
to like the fact that ZPTs (and DTMLs, to a lesser extent), in
combination with PythonScripts, try to stimulate the
scripter/developer to keep logic out of the templates, so I'm not that
thrilled to see the *script* ZPT extension in Zope3.

Now I've been too far removed from zope3 development to know if the
suggestion I'll give is feasible, or if it's too late to propose this,
but I think we should have content space persistent modules.

The way I see them, these scripts would be proper python files. We
might decide to limit what they can contain (for instance, no classes,
or no persistent-inheriting classes).

They could be directly traversable, and invoking them directly would
invoke a special named function (or other callable) within the module
("def index_html(request):"?).

Another possibility is to have some way of declaring a function (or
other callable) within this module so that it might be called without
parameters by a ZPT (e.g. in a path expression) but would
automatically receive the ZPT's parameters (options).

I think this would be a nice option for scripters because they'd be
fully formed python files, directly editable with regular editors,
and the callables therein would be easily callable from ZPTs which,
would help keep programming logic out of the templates.

The code in these content-space modules would also be more easily
shareable between ZPTs (which could never happen inside ZPTs *script*
extension, unless we added insult to injury by having some way of
importing the scripts of one ZPT from another. Damn, I shouldn't have
even mentioned it, lest some adventurous soul try to implement it :-).

Last, but not least, this would provide an easy migration path from
scripters to developers as the content space modules could be easily
transplanted to software space.

So what do you think? Am I totally off base here?

Cheers, Leo