Re: RFC: Proposal Dexterity API - two variants

I think we need to clarify the context of what we are talking about.

Dexterity has been choosen beeing the replacement for archetypes and the 
content type story. As such i expect all the features at least in a 
similar way i had with archetypes. From a programmers point of view.

It feels that the TTW aspect gets focused as the most important one 
here, and in my opinion, it's not. We still are writing our addons, 
customer implementations, contents types, views in python eggs, with GS 
integrations, tests and such.

All the TTW stuff is a nice thing to get started with, for small 
installations and for prototyping, but when it comes to long term 
maintainable applications, at least i have not seen a big plone project 
which gets maintainerd TTW only. Especially when it comes to complex 
data and security schemes.

And i think one of the most important takling points for plone is the 
reliability on - even if somewhat strage looking - stable and secure 
model and code.

As developer working on plone projects since 2004, i see behaviors as a 
replacement to archetypes.schemaextender with the advantage that each 
behavior typically comes along with an interface set on the content 
intstance once this behavior is applied. And here is the big strength - 
now i'm able to integrate into the application in terms of components, 
with respective data adapters, views, field permissions, event 
subscribers, indexing, etc.

And i think this is the context in which this API discussion has been 
started, and in which the advantages and disadvantages should be discussed.

When it comes to to the explanation between TTW fields and behaviors, we 
need to see the behaviors as what they are; components adding a more or 
less complex functionality to content objects, including all the 
surrounding (as described above), and a field is simply a snippet of 
data, without much application semantics bound to it.

To answer complaints about restricted python and access to a dedicated 
data holding attribute as mentioned in a prior post, it's possible to 
explicitely expose attributes to restricted code. see 
https://pypi.python.org/pypi/RestrictedPython#examples as starting point

Robert

Am 2014-11-05 um 20:02 schrieb Steve McMahon:
> 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 
> <[email protected] <mailto:[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]
>     <mailto: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
>         <mailto: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
>     <mailto: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