Re: How to edit dexterity types without needing to know about their behaviors

Johannes Raggam <[email protected]>
Newsgroups gmane.comp.web.zope.plone.devel
Message-ID <[email protected]>
On Thu, 2014-03-13 at 22:33 -0700, ajung wrote:
> > 
> > Some can be accessed and set directly without adaptation. Other cannot.
> 
> This is the whole key issue. Direct set/get access is one of the key
> Dexterity paradigms. Being more pythonic was one of the design goals of
> Dexterity. Direct access is what we prayed, what we learned and what we
> thought to other people. There is no way out of this paradigm - no
> exceptions - no excuses - never ever. There can not be a difference between
> first-class and second-class attributes (introduced through a behavior). And
> there is no need for a developer to lookup specific behaviors or interfaces
> for getting and setting values of a content-type instance. Consistency is
> king, ease-of-use is king -  no exceptions. Philipp fired "RTFM" last night
> at me. I just answer "why"? We learned that direct attribute is the way to
> go modify content-type instance....why should I, why should Plone non-core
> developers be obliged to check the implementation of every possible
> content-type for exceptions? So there are just two options: we stick with
> the direct atttribute access pattern as proclaimed for year or we say
> "sorry", our approach is flawed and we need a consistent API.  I can only
> emphasize once more that this is such an important key issue - especially
> when you want to marked Plone to other developers. The team I am coaching
> right know would only their eyes.

when i first encountered behaviors back in 2010 (IIRC) i was a bit
puzzled about having always to adapt behaviors in order to be sure to
get/set the right thing. but that concept is as old as dexterity is. so
IMO that was not a key paradigm.

but i agree, it's not obvious to have to adapt an event context with a
behavior and it's a different API to the plone.app.contenttypes. to
p.a.event's defense defense: it is older, and it's also documented:
https://github.com/plone/plone.app.event/blob/master/docs/development.rst#getting-and-setting-properties

i'll fix that, probably at the wine and beer sprint. but then you'll
still always get UTC datetime values instead of localized ones, if you
get the start/end attributes directly from the context.

> Consistency-is-king
> Andreas

pragmatism is okay.
johannes

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers
signature.asc (application/pgp-signature, 198 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEABECAAYFAlMivqUACgkQW4mNMQxDgAfrGwCdFF4vDpgcHHfgYttGgsi5NqfN
WGAAn3TdxfGMMdqaricRaeDT8UULZtfi
=M8LC
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.