Re: RFC: Proposal Dexterity API - two variants

First time, when I encountered behaviors some years ago, I really
disliked the need to adapt a context to the behavior interface in order
to get or set attributes to it.

However, behaviors give you a lot of power by allowing you to mix-in
different schemata to content types or enrich them with another
behaving.

It was an intentional decision to implement the Dexterity part of
plone.app.event as behaviors instead of content types and schemata. It
was always meant that these event related behaviors would be added to
any other content type.
This concept is so powerful! I still stand behind it, even I see it
gives you a clumsy API.
The change from content type schemata to behaviors in
plone.app.contenttypes followed the same intentions.
bdap.plone.shop is another example of leveraging the power of behaviors
AND archetypes.schemaextenders, by allowing to make any content type a
shop item.

Maybe the behavior-adapter API is not all that bad. You can teach
developers to use and getting an absolute flexible concept in return.
Maybe the content type schemas should be dropped and everything done via
behaviors instead, so that we don't have multiple concurring API
concepts.

Regarding the RFC, I'd favor Option 1 "Explicit behaviors proposal".

Johannes



On Wed, 2014-11-05 at 11:02 -0800, Steve McMahon wrote:
> I've a challenge for those who have looked at the dexterity interface
> with plone.app.contenttypes installed:
> 
> 
>         Try to see if you can describe -- or document -- the
>         difference between fields and behaviors to Dexterity's
>         principle audience. That's people starting content-type
>         development TTW.
>         
>         
> I fear we are currently in a situation where this is close to
> impossible.
> 
> 
> The problem with attribute access is a symptom of this. We are
> bringing in a lot of fields via behavior. We have the potential for
> namespace collision if those fields are simple attributes, and the
> problem of API complexity if they aren't.
> 
> 
> 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.
> 
> 
> I'm fearing, though, that it's not the right solution. Consider one of
> the most common varieties of customization a TTW user might wish to
> make: changing the title or description of a field like the title or
> description.
> 
> 
> I can think of some possible solutions; I'll be others can come up
> with some, too. But, first step, do we agree we've got a problem here?
> 
> 
> Steve
> 
> 
> 
> On Wed, Nov 5, 2014 at 8:57 AM, Martin Aspeli <optilude
> [email protected]> wrote:
>         Hi,
>         
>         
>         When Dexterity was first designed this was the thinking:
>         
>         
>          - Anything that belongs to "your" content type is in "your"
>         schema and is available as attributes on "your" type.
>          - If you personally want to reuse among your types, just use
>         subclassing. Simple, effective.
>          - Behaviours are a way for programmers to build things that
>         non-programmers can use TTW. That is, behaviours lets you
>         declaratively opt into certain things (the canonical example
>         was "versioning") without having to understand how they're
>         implemented.
>          - Behaviours can work either adapter-like (data stored
>         elsewhere, e.g. in annotations or centrally somewhere) or
>         marker-interface-like (data stored on the object).
>         
>         
>         I think where maybe we've gone a bit wrong is that we seem to
>         have made the decision to ship with very fine-grained
>         behaviours that form part of the primary API to objects when
>         we think about the Dublin Core metadata.
>         
>         
>         That is a special case and arguably one that should be handled
>         with only one or a small number of behaviours, which should by
>         and large be of the market interface variety. So, if you are
>         writing very generic code, then you may want to check or do an
>         explicit adaptation (remember that you can adapt to an
>         interface that is directly provided by an object without an
>         explicit adapter registration).
>         
>         
>         Most people don't write very generic code, though, they write
>         specific code to their specific usecase. That's probably one
>         of three things:
>          
>          - Some custom fields that are reusable. Use a shared
>         baseclass and direct attribute access, behaviours give you
>         little benefit.
>          - Some reusable thing that you want to publish for generic
>         use by third parties. Write behaviours and use the adaptation
>         pattern for safety. I don't really see this as "yet another
>         field", I see this as something with more functionality like
>         rendering additional stuff or something event-driven (there's
>         a reason we called it "behaviours" not "fields").
>          - Some reusable thing you want non-technical users in your
>         project to reuse TTW. Special case of the one above.
>         
>         
>         I don't like the idea of having a dict-like API and an
>         attribute-like API. That's neither very Pythonic nor very
>         clear. Reminds me of the myriad ways we can acquire values in
>         Zope 3 land. It seems to add a lot of complexity for very
>         marginal benefit.
>         
>         
>         Martin
>         
>         On 5 November 2014 15:44, Jens W. Klein
>         <jens-/[email protected]> wrote:
>                 ======================
>                 Proposal Dexterity API
>                 ======================
>                 
>                 We, Robert Niederreiter and Jens Klein, wrote this
>                 proposal as an entry
>                 to a discussion for an future Dexterity API (read:
>                 Dexterity 3). We
>                 followed two different pathes and we are curios which
>                 one gets more +1 ;)
>                 
>                 Both of them are implementable and also both are in
>                 the perspective of
>                 speed almost the same.
>                 
>                 
>                 Explicit behaviors proposal: expose behaviors
>                 explicitly
>                 ========================================================
>                 
>                 Basic principles
>                 ----------------
>                 
>                 * Duplicate attribute names are allowed by different
>                 behaviors
>                 * Programmer always addresses effected behavior
>                 explicit
>                 
>                 
>                 Pros
>                 ----
>                 
>                 * More reliable and readable code
>                 * Explicitness
>                 * Easy migration
>                 
>                 
>                 Cons
>                 ----
>                 
>                 * Steeper learning curve (developer needs to learn
>                 which behaviors exists)
>                 * More code
>                 
>                 Implementation implications
>                 ---------------------------
>                 
>                 * think of behavior inheritance and how default
>                 behaviors can be overwritten
>                 
>                 
>                 API usage example
>                 -----------------
>                 
>                 Read Attribute::
>                  >>> context.behavior('basic').title
>                 
>                 Write Attribute::
>                  >>> context.behavior('basic').title = u'My Title'
>                 
>                 Behavior information::
>                  >>> context.behaviors
>                 {
>                      'basic': {
>                          'title': 'Basic',
>                          'description': 'Foo',
>                          'attributes': {
>                              'title': {
>                                  'label': 'Title',
>                                  'description': 'Title of the object',
>                                  '...'
>                              },
>                              ...
>                          }
>                      }
>                      ...
>                 }
>                 
>                  >>> repr(context.behaviors)
>                 - basic
>                      -title
>                      -description
>                 ...
>                 
>                 Unrestricted access::
>                  >>> context.behavior('basic').unrestricted('title')
>                 
>                 
>                 Shadowed Behaviors Proposal: Simplified value access
>                 ====================================================
>                 
>                 Basic principles
>                 ----------------
>                 
>                 * implemented as one property directly on
>                 plone.dexterity.content.DexterityContent which acts as
>                 a
>                 zope.interface.mapping.IFullMapping (read: dict-like)
>                 to work with all
>                 values and methods coming from the main schema,
>                 behavior schemas and
>                 behavior factories.
>                 * Programmer does not need to know about behavior
>                 names when accessing data
>                 * Set/get of main schema values is same as schemas
>                 form behaviors.
>                 * Duplicate attribute names are NOT allowed any more
>                 and enforced
>                 (checked on FTI creation time, i.e. XML import, TTW
>                 setting) This is
>                 important!
>                 * factory methods/properties from behaviors are
>                 exposed when a factory
>                 is given instaed of direct attribute access.
>                 
>                 
>                 Pros
>                 ----
>                 
>                 * Simple entry for new developers
>                 * pythonic
>                 * natural dict-like API is first principle
>                 * no accicdential override of attributes stored
>                 * behavior inheritance (i.e.IDublicCoreMetadata is not
>                 a problem at all)
>                 
>                 
>                 Cons
>                 ----
>                 
>                 * duplicate fieldnames in existing code needs
>                 migration (not in core)
>                 * behaviors are kind of hidden to developers, so
>                 misunderstandings may
>                 occur (needs good documentation)
>                 
>                 
>                 Open for discussion
>                 -------------------
>                 
>                 * should validation be enforced?
>                 
>                 
>                 Important
>                 ---------
>                 
>                 * lots of caching of schemas and intermeidate results
>                 
>                 
>                 API usage example
>                 -----------------
>                 
>                  >>> context.values['title']
>                 'My Document'
>                 
>                  >>> context.values['title'] = 'Jensens Document'
>                  >>> context.values['some_factory_property'] = 'Foo'
>                  >>> context.values['some_factory_property']
>                 'Foo'
>                 
>                  >>> context.values['some_factory_method'](param1,
>                 param2='foo')
>                 ...
>                 
>                  >>> context.values.keys()
>                 ['title', 'description', ....]
>                 
>                  >>> context.update({'title': 'Jensens Updated
>                 Document', 'description':
>                 'A new easy to understand API for dx'}
>                  >>> context.values.items()
>                 [('title': 'Jensens Updated Document', 'description':
>                 'A new easy ...',
>                 ....)]
>                 
>                 other dict-api methods are implemented too (need to
>                 finish this, but you
>                 can imagine how it looks like, )
>                 active access to restricted values which checks the
>                 read/write permission!
>                 
>                  >>> context.restricted_values['title']
>                 Traceback ...
>                 ....
>                 Unauthorized(...)
>                 
>                 
>                 Legacy Proposal
>                 ------------------------
>                 
>                 * rename dexterity to devilstick
>                 * use wording molecule instead of behavior
>                 * the values are atoms
>                 * ignore this legacy proposal ;D
>                 
>                 -------------------------------------------------------------------------
>                 
>                 happy commenting
>                 
>                 Jens and Robert
>                 --
>                 BlueDynamics Alliance
>                 
>                 
>                 ------------------------------------------------------------------------------
>                 _______________________________________________
>                 Plone-developers mailing list
>                 Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>                 https://lists.sourceforge.net/lists/listinfo/plone-developers
>         
>         
>         
>         ------------------------------------------------------------------------------
>         
>         _______________________________________________
>         Plone-developers mailing list
>         Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>         https://lists.sourceforge.net/lists/listinfo/plone-developers
>         
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Plone-developers mailing list
> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/plone-developers

-- 
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
plone framework  team  member
mail: office-//[email protected]
web:  http://programmatic.pro
      http://bluedynamics.com

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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEABECAAYFAlRajxQACgkQW4mNMQxDgAcwkQCfe545dF7Irrc5FEjDcVMfbxIS
STMAnR5Qk/cjnP8L2C7gF2cfTNHhbXFL
=81tv
-----END PGP SIGNATURE-----