[Product-Developers] Re: Experiences with commenting solutions

Kai Diefenbach usenet at diefenba.ch
Fri Jul 4 15:32:26 UTC 2008

Hi Martin, 

Martin Aspeli <optilude at gmx.net> wrote:

> >> 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.

I see. 

> >> 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
> detail.

I've got it! 

I will take your advice into account for future releases. Thanks for
this elaborations.


iqplusplus - http://iqpp.de
EasyShop - http://www.geteasyshop.com

More information about the Product-Developers mailing list