Hi,

On Sun, 2009-05-31 at 18:04 -0700, Ross Patterson wrote:
> Tim Knapp <[email protected]> writes:
> 
> > As I'm using betahaus.emaillogin[1] in my application I'm wanting to
> > override the generation of the username as this is a little confusing
> > for users as they expect to login with their email address but we're
> > still asking them to enter a username.
> >
> > I've tried to override this as follows in my member schema:
> >
> >     # Overriding the id field as we're using betahaus.emaillogin
> >     atapi.ComputedField('id',
> >                        expression = "context.setId()",
> >
> > index=('membrane_tool/ZCTextIndex,lexicon_id=member_lexicon,index_type=Cosine
> >  Measure|TextIndex:brains',
> >                               'FieldIndex:brains'),
> >                  widget=atapi.ComputedWidget(label='User name'),
> >                  regfield=0,
> >                  user_property=True,
> >                  ),
> 
> Thus far I don't think I'm understanding the intention of certain
> choices in your implementation enough to comment.  Why use the "setId"
> method?  Wouldn't overriding that wreak all sorts of havoc with the fact
> that membrane members are OFS objects?

Ok, lets start with an overview. betahaus.emaillogin[1] circumvents the
need for a username as it cycles through the members in your site and
authenticates against their email address hence if I also prompt members
for a username when they register with the site its confusing for them
as they wonder "huh, why do I need to enter a username if the system is
going to authenticate against my email address?".

Now what you say re. overriding the setId method may very well be the
case and a bad design choice hence my emailing the list.

[1] http://pypi.python.org/pypi/betahaus.emaillogin/0.2

> 
> > and I've setup the setId method on the member content type as follows
> > (the getName method is an accessor for a StringField where users can
> > enter their fullname):
> >
> >     def setId(self, id=''):
> >         "Overriding the username generator"
> >         import pdb;pdb.set_trace()
> >         if self.getName():
> >             if not getattr(self, 'subscribememberid', None):
> >                 names = self.getName().split()
> >                 if len(names) > 1:
> >                     firstname = names[0]
> >                     surname = names[-1]
> >                     id = firstname[:1]+surname
> >                 else:
> >                     id = names[0]
> >                 catalog = getToolByName(self.context, 'portal_catalog')
> >                 existing = catalog(id=id, portal_type='Subscribemember')
> >                 if len(existing) != 0:
> >                     try:
> >                         i = int(id[-1])
> >                         id = id+str(i+1)
> >                     except:
> >                         id = id+'1'
> >                     return self.setId(id)
> 
> Wouldn't this result in a recursion error?

Actually you're right. Should've doublechecked my code but the point is
that it doesn't even enter this method otherwise I would've seen this
obvious issue.

> 
> >                 else:
> >                     setattr(self, 'subscribememberid', True)
> >             else:
> >                 return getattr(self, 'subscribememberid')
> >
> > As you can see I just grab the first initial of the firstname and the
> > surname and then check that no user exists for that username.
> >
> > When I run my functional test, though, it doesn't create the user and
> > doesn't even enter the setId method (as you can see I've got a pdb in
> > there). Its supposed to return 'You have been registered as a member.'
> > but instead I get 'Changes saved.' as a status message.
> 
> Care to include the test or at least some snippets from it?

Its a functional test (i.e. what the user sees when using the site) so
so it won't illuminate you on my usecase. IOW it just shows the user
register with the site (enter values and click 'register).

> 
> > Any tips on how I *should* be implementing this?
> 
> Maybe Rob will understand better what you're trying to do but for my
> sake, can you describe in more detail why you went this direction?  Once
> I understand better I'll be able to comment.

See above.

Thanks,
Tim

> 
> Ross
> 
> 
> 
> --
> Archive: 
> http://www.openplans.org/projects/remember/lists/remember/archive/2009/05/1243818339697
> To unsubscribe send an email with subject "unsubscribe" to 
> [email protected].  Please contact 
> [email protected] for questions.
> 



--
Archive: 
http://www.openplans.org/projects/remember/lists/remember/archive/2009/05/1243825607093
To unsubscribe send an email with subject "unsubscribe" to 
[email protected].  Please contact 
[email protected] for questions.

Reply via email to