Re: RFC: Proposal Dexterity API - two variants

I agree TTW development is not the subject here.
The TTW experience must be improved in Plone, and, yes, it is certainly a
valid approach to Plone development.

Nevertheless, TTW developers and classical developers haven't the same
expectations nor the same programming skills.
And we cannot make a unique content-type API that would fit those two
audiences.
The API proposed here will be used by classical developers crteating their
own specific add-ons.
Regarding behavior usage, hiding explicit adaptation is probably nice, but
hiding completely the behaviors existence would be annoying, as behavior is
a concept those developers will have to handle anyhow.

+1 for "Explicit behaviors proposal: expose behaviors explicitly"

Eric

On Wed, Nov 5, 2014 at 9:13 PM, Robert Niederreiter <rnix-vzgNpXZZ1Rwgm7i/[email protected]>
wrote:

>  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]>
> 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 listPlone-developers-5NWGOfrQmneRv+LV9MX5ugtCRVl27V+i0wdF1cv0I5s@public.gmane.org://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