Hi Martin, Martin Aspeli <[EMAIL PROTECTED]> 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. Kai -- iqplusplus - http://iqpp.de EasyShop - http://www.geteasyshop.com _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
