Hey,

See my responses below...

On Jul 21, 2006, at 6:14 PM, Rob Miller wrote:
> http://dev.plone.org/collective/changeset/26308:
>
> * in MemberDataContainer.getAllowedMemberTypes(), you're returning  
> a list of all the registered membrane types.  the registered  
> membrane types, however, can include objects that are property  
> providers, group providers, role providers, etc., in addition to  
> authentication providers.  what we really need is to get away from  
> thinking of a member "type" and to start thinking of a member  
> "policy", so someone could register and then get the correct set of  
> objects created.  at the very least, though, we should be filtering  
> so that only auth provider objects are returned, though.

I'm not sure I know what you mean about making it a "policy".  Is the  
idea that multiple content objects could represent the schema of your  
member?

> * ultimately, we want to get away from depending on the  
> MemberDataContainer altogether.  it would be much better if  
> "defaultType", and any other member-related config information we  
> want to store, were managed via a Z3 schema that can be associated  
> w/ the MembershipTool, exposed via formlib.

I'll look at doing up the membership tool to be our one stop shop for  
membership related data like the default member type.

> http://dev.plone.org/collective/changeset/26290:
>
> * the MemberDataContainer.searchForMembers() method doesn't really  
> belong on the MemberDataContainer any longer.  instead, there  
> should be an adapter for IMembraneTool that provides a new  
> interface called IMembraneSearch, which can expose a  
> searchForMembers method.  the MembershipTool would retrieve the  
> MembraneTool and adapt it to IMembraneSearch to actually perform  
> searches.

Agreed,  I think I see now where you are going with this.  I'll  
refactor that part into an adapter on the membrane tool.

> * the MembershipTool should no longer assume that all member  
> objects live in portal_memberdata.  we can introduce a  
> "defaultMemberContainer" config option where new member objects  
> will be placed, but addMember should take an optional "container"  
> argument as an alternative.  and "deleteMembers" (which should  
> ultimately delegate to some member deletion policy) should find the  
> member objects by doing catalog searches rather than by assuming  
> the objects live in portal_memberdata.

I like the idea of this, but time may not permit us to implement it  
yet.  This doesn't seem hard to put into a next release though since  
the migration would only involve the membership tool itself.


> GENERAL:
>
> we need some unit tests, there are only two right now.  i don't  
> expect you to cover the entire codebase (and anyway, most of the  
> hard work is done by membrane, which has reasonable coverage), but  
> it would be great to get some tests on at least what you've worked  
> on, such as a couple for the new registration tool, and a few for  
> the member searching and member addition / deletion stuff mentioned  
> above.

This will have to be time permitting on our side which isn't looking  
likely right now.  The load here is pretty high, but luckily I think  
we have 3 projects coming online that will need it.  So we might be  
able to spread it across them all.

> all in all, though, it's coming very well!  thanks so much for the  
> work you've already done!

Great,  I'm glad it is somewhat in line with what you had  
envisioned.  We look forward to a release.

Thanks,
Calvin

-- 
S i x  F e e t  U p , I n c .  |  "Nowhere to go but open source"
Silicon Valley: +1 (650) 401-8579 x602
Midwest: +1 (317) 861-5948 x602
Toll-Free: 1-866-SIX-FEET
mailto:calvin@...
http://www.sixfeetup.com  |  Zope Hosting from $19.95/month