Re: RFC: Proposal Dexterity API - two variants

On 11/5/14, 2:37 PM, Martin Aspeli wrote:
>
>
> On 5 November 2014 20:26, Asko Soukka <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     Steve McMahon <[email protected] <mailto:[email protected]>> kirjoitti
>     5.11.2014 kello 21.02:
>
>>     I think I understand why the current plone.app.contenttypes is
>>     doing so much via behaviors. It's a way to solve the problem of
>>     having the standard content types be relatively customizable. If
>>     the fields were frozen in schema or Python-package-base model
>>     files, you wouldn't be able to turn fields on and off.
>
>     Yet, when it comes to customization, behaviors can only be turned
>     on and off. E.g. their fields cannot be reordered or otherwise
>     customized.
>
>
> This is true. But the question is, is this a real use case? I'd see a 
> couple of "sensible default"  use cases here:
>
>  - Switch off a group of things, e.g. a tab's worth of fields. That's 
> how the DC behaviours in p.a.dexterity were designed from memory.
>  - Switch off everything: my type doesn't need any of the DC stuff
>  - I want something unique... switch off the things I don't want and 
> maybe add one or two of them back, or do something more clever in Python
>
> The point is that having lots of declarative customisability (the 
> behaviour-per-field approach) adds a cognitive cost that counters the 
> benefits of having toggleable/re-usable things in the first place. At 
> some point it just becomes easier to do it in code. And we will always 
> have regular composability of interfaces and base classes in Python.
>
> I think behaviours are always going to be an "80%" solution. I hope 
> they'll be a rather good "80%" solution so that people who don't want 
> to write complex code can re-use some complex code ("I want versioning 
> for my type" or "I want audit logging for my type") in a declarative way.
>
> Behaviours are not and were never designed to be a way simply to build 
> reusable fields.

Well, we need a better way to do reusable fields then.

This is a real use case: As an integrator, I want to install an add-on 
which provides some functionality I can enable for my types (for example 
a geolocation field), but I want to retain control over where it appears 
on my edit forms, and maybe change the label and help text.

------------------------------------------------------------------------------

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers