[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