On 8/7/09 12:02 , Ralph Jacobs wrote:
Wichert Akkerman wrote:
On 8/7/09 09:51 , Ralph Jacobs wrote:
Author: ralphjacobs
Date: Fri Aug 7 07:51:00 2009
New Revision: 93885
Modified:
Products.PlonePAS/branches/plip9305-fullname/Products/PlonePAS/tests/test_membershiptool.py
Products.PlonePAS/branches/plip9305-fullname/Products/PlonePAS/tools/membership.py
Log:
Simple Implementation of getFullname and added testGetFullName in
test_membershiptool
What is the point of the API extension? This should be done through
the already existing getMemberInfo imho.
Wichert.
Hi Wichert,
We are working on PLIP ticket #9305, see:
https://dev.plone.org/plone/report/24
and http://lists.plone.org/pipermail/framework-team/2009-July/003071.html
I understand that you are implementing a PLIP, but I just want to point
out that there is a long existing API with proper permission handling
which returns member information, including the full name: the
getMemerInfo call. That method is just as expensive as your new method,
so performance is not a valid argument.
I'm afraid I also don't buy the lookup mechanism mentioned in the PDF:
you are essentialy creating a persistent cache system, which means that
suddenly page views can trigger ZODB writes, which is very bad for high
performance sites. It also will miss all user changes created directly
in external user sources such as LDAP, AD and SQL databases, leading to
incorrect and possibly correct behaviour.
If there is a performance problem, which has not been proven yet, it
should imho be solved at a different point. All the required PAS methods
are already ZCacheable, so that is not expensive. The single object
wakeup to get the users member data is also not that bad, and I would be
very surprised if that shows up in a real world profile.
Wichert.
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
