[Framework-Team] Re: wicked integration w/ plone 3
Martin Aspeli
optilude at gmx.net
Sat Jan 6 00:31:39 UTC 2007
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
More information about the Framework-Team
mailing list