Re: RFC: Proposal Dexterity API - two variants

Am 2014-11-05 um 23:31 schrieb Martin Aspeli:
>
>
> My overarching hypothesis is that your pain is felt because of the 
> particular way that p.a.contenttypes has chosen to use behaviours and 
> the implications for "good practice". I'd rather fix that than 
> introduce another API for value access, which sounds like the kind of 
> thing we may regret in a few years' time.
After implementing some addons with dexterity my conclusion is that 
behaviors should be the only way providing and extending functionality 
on content instances, with usecases in mind, where behaviors might be 
assignable per content instance in future by default, i.e. having a 
document and want to add a geolocation to this specific instance. Still 
fine then with TTW editing and adding of fields on base TTW types.

It's also not really "my pain", i am fine adapting behavior interfaces 
for gaining it's attributes the right way. The original discussion has 
been started in a blog post and another thread by andreas jung, and the 
discussion has evolved further in bristol, so there are real experiences 
from migration projects and real complaints from the community that 
"something needs to be done"

> If the alternative is a magic dict to access that you access with 
> string keys then I don't think we're gaining anything. Jens' examples 
> in the original mail look very worrying to me:
There have been two proposals in our original mail, first one only hides 
ZCA a little bit and add some debugging convenience.

>  - The values object isn't a dict, it's something that looks like a 
> dict and behaves kind of like a dict except when it doesn't
In the python docs the provided API is not related to dictionaries only. 
it's just called dict-like here because most people know the syntax 
immediately, other if it's called what it is -> emulating container 
types -> 
https://docs.python.org/2/reference/datamodel.html#emulating-container-types
>  - There's another magic thing called restricted_values which gives 
> you different behaviour
I guess this is some kind of mistake here, goal would be to have 
restricted access by default (checking field permissions and such) and 
an unrestricted lookup explicitely, like

 >>> context.values.unrestricted('title')
>
>
> I think if you have a use case where this indirection is needed (e.g. 
> you are building some kind of very generic framework) then it'd be 
> easier to build that off a particular base class.
Subclassing pops up more problems than it solves here in my experience.

Robert

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

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