Re: RFC: Proposal Dexterity API - two variants

Hi,

On 5 November 2014 20:13, Robert Niederreiter <rnix-vzgNpXZZ1Rwgm7i/[email protected]> wrote:

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

I didn't say that. What I said was that the original use case for
*behaviours* had evolved from a desire to allow people to build reusable
components that could be reused TTW or by less experienced developers.
Archetypes had no direct analogy of this. at.schemaextender is obviously
the closest thing, but it does work somewhat differently.

I agree that Python development is by far the most important use case.

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.


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

I kind of agree, but this is a very advanced use case. I think if you are
really capable of designing and working in a context where fields can be
applied extrinsically to the definition of the type, then having you opt
into using adaptation syntax (*IMyBehaviour(context)*) is really not a very
big ask.

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:

 - String indexing is typo prone
 - You have to know about the values object
 - 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
 - There's another magic thing called restricted_values which gives you
different behaviour

This doesn't feel very Pythonic to me.

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.

Martin

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

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