[Framework-Team] [Plone-developers] PlonePAS portrait handling

Radim Novotny novotny.radim at gmail.com
Wed May 2 15:32:18 UTC 2012


Hi all,

I've started Plone Portraits PAS plugin work a long time ago and also 
created a PLIP proposal (which has been closed because of PLIP policy 
change - https://dev.plone.org/ticket/11323 ) It is slightly different 
what Jens is suggesting. It defines new PAS plugin and allows to use eg. 
Gravatar or LDAP. The plugin is backward comaptible with the current 
implementation, because implements ZODBPortraitProvider plugin.

The current implementation is available on 
https://github.com/naro/Products.PlonePAS The example plugins are 
Memberdata 
https://github.com/naro/Products.PlonePAS/blob/master/Products/PlonePAS/plugins/portraits.py 
or Gravatar 
https://github.com/naro/Products.PlonePAS/blob/master/Products/PlonePAS/plugins/gravatar_portrait.py 
or read-only LDAP 
https://github.com/naro/Products.PlonePAS/blob/master/Products/PlonePAS/plugins/portrait_ldap_demo.py

-- 
Radim





>
> On Apr 11, 2012, at 2:28 PM, Jens W. Klein wrote:
>
>> Products.PlonePAS handles every user data as some property on a
>> propertysheet, except the portrait photo.
>>
>> The portrait is stored at portal_memberdata - which is fine - but it is
>> not exposed on the property sheet nor is it fetched as such.
>>
>> In my opinion its a must to handle the portrait photo the same way as
>> all userdata. Exposing a photo from a different source - i.e. ldap, sql,
>> remember - means now to patch PlonePAS - and this is ugly and error-prone.
>>
>> I'd like to change PlonePAS in a way to support this, but before I start
>> I'd like to read your opinions.
>>
>> My proposed changes are:
>>
>> - add a new mutable propertysheet dealing with one property 'portrait'
>>    and use current portal_memberdata storage
>>
>> - change the methods used to fetch, store and delete the portrait on
>>    portal_membership and portal_memberdata to use the propertysheet.
>>
>> - add a traverser to the photo to support non-zodb data.
>
> I would like this but, how would this work? How does the PAS story fit in here?
>
>>
>> - add tests
>>
>> Code using the current API would not be affected. Supporting a different
>> data source for the photo would follow the usal PAS API.
>>
>> What do you think?
>>
>> Do we need a PLIP for this?
>
> I'm all for this idea. I feel like a plip would just help with the review process more than anything. I wouldn't mind deprecating the old way either and making a plip would help this happen. I doubt the FWT would say no to this and I know I have a project that could use this functionality.
>
> Liz
>
>>
>> regards Jens
>> --
>> Klein&  Partner KG, member of BlueDynamics Alliance
>>
>>
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> _______________________________________________
>> Plone-developers mailing list
>> Plone-developers at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/plone-developers
>




More information about the Framework-Team mailing list