Hi Whit,

this is pretty much the idea behind wicked.fieldevent[1]. txtfilter is actually re-implemented as an example in wicked.fieldevent but it was more efficient to register wicked directly as a subscriber to render rather than put it into a txtfilter pipeline. If you're filters are orthogonal(ie don't require sequential dispatch), registering them directly as fieldevents will work quite nicely. since we can do persistent components now, registering and unregistering the behavior should be super easy(mainly an interface management problem)

I hope you'll promote and document this a bit :)

It does sound very cool.


One thing that concerns me a little (not a lot) is that wicked seems to be a fairly all-encompassing package. That is, it has Plone specific things and field event stuff and wicked syntax stuff and I'm guessing Zope 2/CMF stuff, all in the same package. Or did I misunderstand?

I need to make a new review bundle....since I started working with wicked as a python lib, I've yet to change a single line of code outside of wicked and there for have been a bit tardy in doing so.

essentially the review bundle will be


+ the plone 3 bundle

and then link in one of the zcml configurations from wicked.plone to your etc/package-includes and link wicked into lib/python(if you aren't using workingenv)

If you are interested in trying it.

Otherwise, I'll fix up a proper bundle this evening

We don't really do package-includes (hard to deploy, package for installers etc); what we have tended to do instead is that CMFPlone/configure.zcml has a bunch of <import package="plone.something" /> at the top.


Framework-Team mailing list

Reply via email to