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-----