[Product-Developers] Re: Experiences with commenting solutions

Martin Aspeli optilude at gmx.net
Fri Jul 4 07:53:11 UTC 2008

Hi Kai,

>> A minor niggle is that the fields in the custom templates don't use
>> class="field" on their divs, making them look funny. :) Another is that the
>> ICommentingOptions adapter seems to create annotations on the fly in
>> __init__() (i.e. when it's adapted) which is pretty bad since it could lead
>> to write-on-read situations. Oh, and it installs an action called "options"
>> that is available even on types where the view it links to are not. Using
>> the schema extender on ICommentable would be better.
> I never used schema extender yet so I'm not really sure what you mean. 
> Do you mean to use schema extender to add the options field into the
> schema of the ICommentable rather than use a own form available via an
> action?

I don't think the "options" action (bad name, btw, since it's too 
generic) is all that useful. In most cases, you just want to be able to 
turn comments on or off, which we already have a field for in 
Archetype's ExtensibleMetadata - see my second attempt at an adapter 
below - that an ICommentable adapter can just use.

The only other option I think would be useful, would be whether to 
override the "enable moderation" status, and *possibly* to be able to 
have an email address for new comments, although that's probably 
overkill and may mean that a global policy is harder to enforce.

For all other options, the global control panel will suffice.

I'd use schema extender to add a new tickbox like the "allow comments" 
one that acts like an on/off switch but reflects the global default if 
not explicitly set. You can save the actual value in the annotation you 
use anyway.

>> Not respecting the FTI option and registering a blanket adapter on for
>> BaseContent is the biggest problem, though. This means that you get comments
>> on things that aren't really content and there's no per-type setting. I
>> fixed it with an override adapter like this:
>> [snip]
> Point taken.
>> I think it's a bit annoying that these things are using string-based option
>> checking, but oh well. All in all, the product is very good.
> What would be the better approach? Defining constants in config.py and
> using that?

No, I meant ... the adapter has fields is_enabled or whatever. However, 
those just check the local value. You have to call getEffectiveOption() 
to get the real value, as far as I can tell.

The natural interaction pattern would be:

  options = ICommentingOptions(context)
  if options.is_enabled:

In that sense the propery getters should act as getEffectiveOption does 
now. The very notion of an "effective" option and the global/local 
hybrid is too much of an implementation detail for me. If you look at my 
override, I had to hack around it with an explicit string check, because 
all the framework code that's doing something with this adapter calls 
the method with the string, rather than calling the attribute getters.

I should be able to plug in a different policy and customise the 
behaviour of the individual properties easily. The fact that the default 
adapter has a global default and a local override is an implementation 


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

More information about the Product-Developers mailing list