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
detail.
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See
http://martinaspeli.net/plone-book_______________________________________________
Product-Developers mailing list
Product-Developers@...
http://lists.plone.org/mailman/listinfo/product-developers
attachment0 (201 bytes) 
