miles at jamkit
Mar 18, 2009, 10:02 AM
Post #6 of 10
>> We have quite a lot of copy-and-paste code here in order to support
>> using a custom MemberData class for members in particular sites.
>> The reason for this is that the only way to use a different MemberData
>> class is to provide a custom wrapUser method.
>> I'd like to propose that this is changed to use a factory registered
>> through the CA to create new MemberData objects, in order that this is
>> pluggable without requiring a custom MemberDataTool.
> Can you explain the use case? I suspect you can also solve this with PAS
> and a custom user factory PAS plugin.
Sure. Example use cases are fairly simple things like:
- I set members to have first_name, last_name, job_title attributes
I want to give them an attribute "proper_name" that returns
'%s %s (%s)' % (first_name, last_name, job_title);
- I want to provide a standardised sortable name for ordering rows,
e.g. (last_name + ' ' + first_name).lower()
- I want to adjust the setProperties method to add a 'modified'
attribute that's adjusted on every change of details
For sites with integration we use PAS. But for small sites with very
simple member requirements, the MemberDataTool generally does most of
what's required out of the box.
Zope-CMF maillist - Zope-CMF [at] lists
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests