Funny thing is, it does not even show the "remember" type. I implemented Jim Baack's suggestion, which provided me a workaround to the issue.
I built a buildout version of Plone on windows so that I could step through it with WingIDE, but that version functions perfectly (naturally!). I believe it to be a deeper issue than remember - I think it's really an issue (bug?) with the archetype machinery....so I'm contenet to let it return Membrane types. I'm happy to answer any questions on my setup that's failing. It's a Plone 3.1.7 buildout install on CentOS5.1, zeo + two instances, plus quite a few products (perhaps too many to list here). Jim - thanks again for the workaround! --Scott ----- "Rob Miller" wrote: > From: "Rob Miller" <[email protected]> > To: [email protected] > Sent: Tuesday, December 16, 2008 1:45:43 AM GMT -05:00 US/Canada Eastern > Subject: Re: [Remember Mailing List] What determines vaules in the Defualt > Member Type dropdown > > okay, i've finally found a bit of time to look at this. > you may not know this, but there is a full sample custom member type implementation that ships with remember, called (sensibly enough) "sampleremember". this is in the 'examples' folder of the remember package, but it's actually a standalone Zope product. if you want to try it out, you should just copy that directory to a Products directory somewhere and restart Zope. > when i do this, running membrane and remember both from trunk, and i install the SampleRemember product into my remember-based Plone site, then i DO see SampleRemember listed as the default member type in the control panel. you might try this yourself; if it works for you, then you should be able to work out the difference btn what you have and what the sample product is doing to figure out what's missing. > if it doesn't work for you, then we'll have to do more digging, b/c i can't reproduce the problem locally. > On Dec 10, 2008, at 12:34 PM, Scott Brown wrote: Thanks Jim. That may jsut do the trick - I'll report back to the list. > > ----- "Jim Baack" wrote: > > From: "Jim Baack" < [email protected] > > > To: [email protected] > > Cc: "scott brown" < [email protected] > > > Sent: Wednesday, December 10, 2008 3:25:56 PM GMT -05:00 US/Canada Eastern > > Subject: Re: [Remember Mailing List] What determines vaules in the Defualt > > Member Type dropdown > > > > > > ----- "Scott Brown" < [email protected] > wrote: > > > > > I'm still dead in the water on this issue. The non-unicode string did > > > not seem to make a difference. Any suggestions on how to proceed with > > > identifying exactly why I am getting no values in the Default Member > > > types? > > > > > > > Scott, no solution, but I would suggest just trying this for now to move > > forward. Edit remember/utils.py to look like this for getRememberTypes - > > > > security.declarePublic('getRememberTypes') > > def getRememberTypes(context): > > """ > > Return a list of all the membrane types that implement IReMember. > > """ > > attool = getToolByName(context, 'archetype_tool') > > mbtool = getToolByName(context, MBTOOLNAME) > > mbtypes = set(mbtool.listMembraneTypes()) > > #remtypes = [t.getId() for t in > > # attool.listPortalTypesWithInterfaces([IReMember])] > > #remtypes = set(remtypes) > > #return list(mbtypes.intersection(remtypes)) > > return list(mbtypes) > > > > This just ignores the remember interface stuff and shows all membrane > > types. It's been working for me. > this is interesting... it implies that the type is registered with the membrane tool, but that something else is amiss, either the type didn't get registered w/ Archetypes (using the registerType function) or the type is not providing the IReMember interface. > both of these seem pretty unlikely, though. i'm pretty sure that lots would be broken if registerType had not been called. and IReMember is implemented by the member base class.. you'd have to explicitly remove it from the set of provided interfaces. it's pretty easy to do this by using a directlyProvides call when you really want alsoProvides, but if that were the case you'd be wiping out ALL of the implemented interfaces and, again, i'd expect much bigger problems than the type not showing up in the configlet. > if this does fix your problem, i'd be interested in what the exact issue is, maybe you could put a pdb.set_trace in there and poke around to see what's going on? > -r >
