On 2006-07-24 10:40, Calvin Hendryx-Parker wrote:
> 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?

yes.  you can use any number of content objects for properties, for roles, for
groups, etc.  adding a member, then, might actually involve the instantiation
of several different content objects.  the default setup for remember will
collapse this all down to a single content object, but we don't want to code
ourselves into a corner; i expect people who are extending remember will want
to make use of some of these fancy capabilities, and we want to let them. 
> > * 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.

awesome!

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

this one is actually pretty key, i don't want to make a release while this
stuff is hardcoded.  it's not too much work, though, maybe i can get to it
soon. 
> > 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 again!

-r