[Product-Developers] Re: Mixing member properties into AT-based content/Membrane?

Raphael Ritz r.ritz at biologie.hu-berlin.de
Fri Oct 17 11:33:06 UTC 2008


Andreas Jung wrote:
> Hi there,
> 

Hi Andreas,

[..]

> Within a current project Plone users authenticated against LDAP and 
> member properties like name, address and email should be taken from LDAP 
> (the mapping from LDAP to member properties is not the problem)
> and being used directly as properties of Person instances. This means
> that the accessor methods of the related fields of the Person schema
> should access the properties of the related members instead of 
> pre-defined accessor methods performing attribute accesson the instance 
> itself. This is something that can be achieved through Membrane?

I don't know about Membrane but I currently have a very similar
use case for the second time now which made me break out my
initial solution to this into a separate package

https://svn.plone.org/svn/archetypes/archetypes.memberdatastorage/trunk

While there is no release yet, the storage layer has been in
production for a few years now. For convenience, I recently
added the MemberPropertyField.

Here the doc strings:

class MemberdataStorage(AnnotationStorage, StorageLayer):
     """A facade storage which delegates to
     the site's Memberdata Tool for actually
     storing content item field values as
     memberdata values.

     This heavily relies on name magic.
     It is assumed that the corresponding member
     and content instances have *exactly* the
     same id. Furthermore the field names have
     to match corresponding memberdata properties
     unless the member property id is specified when
     instantiating the storage.

     For safety reasons vales are always stored in
     AnnotationStorage (as well) and it automatically
     falls back to it if no associated member can be
     found.
     """


class MemberPropertyField(atapi.StringField):
     """Making member properties managed by the memberdata tool
        available in content space.

        Uses the Memberdata storage layer.

        Overrides the getDefault method to look up existing
        member properties first.

        Per default the field is mapped to a member property
        with the same id as the field's name. To connect to
        a differently named member property, this needs to be
        specified twice: (i) by setting the 'member_property_id'
        on the field and (ii) when setting the storage.
     """

You can see this in use at

   https://svn.plone.org/svn/collective/betahaus.memberprofile/trunk


As I'm currently about to use that on a new site I'm open
for suggestions for further improving it so I would appreciate
your comments (even such as 'great stuff' or 'brain dead -
I'd kill you if I were your client' ;-) ).
Feel free to contribute via the collective right away if
you find this interesting.


Cheers,

	Raphael



> 
> Andreas
> 
> _______________________________________________
> Product-Developers mailing list
> Product-Developers at lists.plone.org
> http://lists.plone.org/mailman/listinfo/product-developers





More information about the Product-Developers mailing list