Personal tools
You are here: Home Lists ZPUG DC List Archives 2005 2005-04 API question / David Diskin <david.diskin@verizon.net>
Navigation
Log in


Forgot your password?
New user?
Mailing Lists
You can read our ZPUGDC mailing list archives online.
You can subscribe to our mailing list:
Book Review

The Definitive Guide to Plone

Reviewer: joel
 

API question / David Diskin <david.diskin@verizon.net>

API question
David Diskin <david.diskin(at)verizon.net>
2005-04-12 22:07:57 [ FULL ]
I seem to have the hardest time finding good documenation about Plone 
and Zope APIS.  Does it exist?  For example, I want to find out about 
portal_registration.registeredNotify().  So, I look in doc below:

http://docs.neuroinf.de/api/plone-api/

It contains very skimpy info:  Here's what I find:

registeredNotify(self,  new_member_id)
  Handle mailing the registration / welcome message.

For example, there's nothing about any exceptions raised.

Am I looking in the wrong places?

Suggestions appreciated.

David
==============================
David Diskin, david.diskin(at)verizon.net
Attachments: 
text.enriched application/octet-stream - 1121 Bytes

Re: [ZPUGDC] API question / jamesr <circlecycle@gmail.com>

Re: [ZPUGDC] API question
jamesr <circlecycle(at)gmail.com>
2005-04-13 00:59:23 [ FULL ]
I won't be very helpful here, but what I do in these situations is to 
look for the documentation in the form of the underlying code. In this 
instance, i'd run a command something like:

grep -r "def registeredNotifiy(" Products/*

in a shell, then look at each of the results. One of them will be the 
definition for the function you are calling, and it's behaviour and/or 
companion methods usually reside either in the class it is a part of, 
or can be tracked down by just getting a sense for where this stuff 
pops up in the code.

for registeredNotify() i find:

[jamesr(at)--- Products]$ grep -r "def registeredNotify(" *
CMFDefault/RegistrationTool.py:    def registeredNotify( self, 
new_member_id ):
CMFPlone/RegistrationTool.py:    def registeredNotify(self, 
new_member_id):

and the function body has:

def registeredNotify( self, new_member_id ):

         """ Handle mailing the registration / welcome message.
         """
         membership = getToolByName( self, 'portal_membership' )
         member = membership.getMemberById( new_member_id )

         if member is None:
             raise 'NotFound', 'The username you entered could not be 
found.'

         password = member.getPassword()
         email = member.getProperty( 'email' )

         if email is None:
             raise ValueError( 'Member %s has no e-mail address!'
                             % new_member_id )

         check, msg = _checkEmail(email)
         if not check:
             raise 'ValueError', msg

         # Rather than have the template try to use the mailhost, we will
         # render the message ourselves and send it from here (where we
         # don't need to worry about 'UseMailHost' permissions).
         mail_text = self.registered_notify_template( self
                                                    , self.REQUEST
                                                    , member=member
                                                    , password=password
                                                    , email=email
                                                    )

         host = self.MailHost
         host.send( mail_text )

         return self.mail_password_response( self, self.REQUEST )

So that, finally, we can see that it will raise a ValueError if the 
email isn't specified, or it fails the _checkEmail method. the 
_checkEmail method itself is located at the bottom of this file.

Note to the adventurous: don't like the way it behaves? go change it - 
restart zope - and walla, you have MutantZope. I sometimes carry around 
specialized products to new projects, (although usually i have the good 
sense to choose to just copy the whole product and make slight 
alterations in that one -- it can be done quickly if you know what to 
look for and change.

On Apr 12, 2005, at 11:22 PM, David Diskin wrote:
[...]
Attachments: 
text.enriched application/octet-stream - 3989 Bytes

Re: [ZPUGDC] API question / Jules <jules@jules.com>

Re: [ZPUGDC] API question
Jules <jules(at)jules.com>
2005-04-13 06:14:29 [ FULL ]
On Apr 13, 2005, at 2:13 AM, jamesr wrote:[...]

You're right, changing the source is great for tinkering. But in a 
production/forgetful environment you're much better off making a Monkey 
Patch as upgrades will be pure hell.

http://www.zope.org/Members/Caseman/Dynamic_HotFix_News/Dynamic_Hotfix

for the gory details.

Re: [ZPUGDC] API question / David Diskin <david.diskin@verizon.net>

Re: [ZPUGDC] API question
David Diskin <david.diskin(at)verizon.net>
2005-04-13 11:08:19 [ FULL ]
Great suggestion!  Thanks.

David

On Apr 13, 2005, at 2:13 AM, jamesr wrote:
[...][...]
==============================
David Diskin, david.diskin(at)verizon.net
Attachments: 
text.enriched application/octet-stream - 4164 Bytes

Re: [ZPUGDC] API question / jamesr <circlecycle@gmail.com>

Re: [ZPUGDC] API question
jamesr <circlecycle(at)gmail.com>
2005-04-13 18:05:44 [ FULL ]
On monkey patch, that's a really cool shortcut! For people who didn't  
look at that link, it's a very simple trick to override any function in  
the zope class collection, so that it's new behaviour is your code  
(good once you copy and paste theirs and tinker it..)

But Monkey Shell iteself is not software or anything -- it's just a  
name for this trick. I didn't think that at first and it makes the  
concept easy. Thumbs up here.
On Apr 13, 2005, at 7:28 AM, Jules wrote:
[...][...][...]

Powered by Plone, the Open Source Content Management System

This site conforms to the following standards: