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.
http://svn.plone.org/svn/collective/wicked/lib/wicked/trunk/wicked/fieldevent/
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
http://svn.plone.org/svn/collective/wicked/lib/wicked/trunk/
+ 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.
Martin
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
