- Zope-Dev - Zope lists

Re: [Zope-CMF] Re: Member tools refactoring (Was: Better MemberData search
by Lennart Regebro 03 Nov '03

03 Nov '03

Miles Waller wrote: > AFAICS, CMFMember covers two sets of requirements: > > - put members through a workflow Very useful. > - use archetypes to configure member objects which behave like normal > zope objects I'm not familiar enough with archetypes to tell what the actual benefits of this is. Could someone summarize?

2 4

RE: [Zope-dev] Etag support in page templates
by Bjorn Stabell 03 Nov '03

03 Nov '03

Just FYI. Apache 2.0.48 now honors caching of pages which only have Expires set (no need to include Etag and/or Last-Modified), but the 1.3 team hasn't responded and so 1.3.29 still has the bug. With mod_deflate site-wide compression of text/html etc, I guess it's enough candy there for me to upgrade:)

1 0

Bare except and ConflictError in manage_beforeDelete
by Florent Guillaume 02 Nov '03

02 Nov '03

I have code that needs to maintain certain invariants when objects are deleted, these invariants are maintained in manage_beforeDelete. Unfortunately manage_beforeDelete has this code: try: if hasattr(aq_base(object), 'manage_beforeDelete'): object.manage_beforeDelete(item, container) except BeforeDeleteException, ob: raise except: LOG('Zope',ERROR,'manage_beforeDelete() threw', error=sys.exc_info()) pass Which means that ConflictErrors in my invariant code get swallowed, and my invariants are broken. This kills me. I want to add an additionnal: except ConflictError: raise Any objections ? Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com

4 4

Zope credits
by Jeremy Hylton 31 Oct '03

31 Oct '03

Dean Goodmanson pointed out that the Zope credits file is a little out of date: http://www.pycs.net/sqr/categories/slicesOfPy/2003/10/30.html#a184 Wouldn't it be nice to get it in better shape for the 2.7 release? It seems like a task that is easy to do in parallel. If credits are too hard, how about an ACKS file like Python's? Jeremy

1 0

Member tools refactoring (Was: Better MemberData search for CMF)
by Lennart Regebro 31 Oct '03

31 Oct '03

Hi all! I'm gonna try to verbalize my thoughts on this subject, but they are still quite fuzzy, so bear with me if I sound confused. :) And sorry for the length of tha mail... Today there are many parts involved in the Member Data Waltz (or is it a two-step). There is the user folder, of course, there is the portal_membership tool and there is the portal_memberdata tool. So what you do is that you ask the portal_membership tool for the information, but it takes the user object from the user folder (which already keeps contains some user data) and then asks portal_memberdata to wrap the user with it's data. Then there is also the portal_registration tool, who also does most of it's things by asking portal_membership. :) Missing from this is both the possibility to do transforms of data, and also the possibility to have several user directories, like for example having most users in an LDAP directory, but some users (like managers) local. To solve this, in CPS there is a portal_metadirectories tool involved (I don't know if there are other alternatives to this for non CPS use), so then we have five different "tools", three of which may store some parts of the actual user data, and all which seem to overlap in functionality in different ways. My suggestion of how to do all this is refactor this into the following pieces: 1. A user folder 2. A user directory tool 3. A membership tool 1. The user folder stays as it is. It will functionally overlap with the user directory a lot, but that is to allow third-party userfolders to still work. I would actually not mind seeing all of the three parts above merged, but I think that should be a Zope 3 thing, in that case. The search API here need only return a list of userIds, btw. If you want the data, ask the membership tool. 2. The user directory tool would basically be a merge of the memberdata tool and CPS's memberdirectory tool. It would contain a set of directories. One could be internal, others could be external. For example one LDAP directory, and one Zope directory. These directories should all implement advanced search functionality. The main directory tool would perform a search by calling the searching on all directories. The tool need to be able to perform transforms. One source may for example store a users fullname in the fields "Name" and "Firstname" another may store it as "Name" and "Family name" and a third just as "Fullname". The tools would need to be able to create a "fullname" property out of these properties. The data may need to be merged for all the users, since you may want to store user data in the Zope directory also for LDAP users. Or maybe this is overkill, I'm not sure. 3. A membership tool, that merges todays membership tool with the registration tool. Again, I think this really should belong in acl_users, but that is not feasible for Zope 2. OK, flame away! //Lennart

2 1

New Zope Database Adapter Test Suite available
by Chris Withers 31 Oct '03

31 Oct '03

Hi All, I've just finished writing a test suite for Zope DA's in general, based on what I saw in Shared.DC.ZRDB.Connection and Shared.DC.ZRDB.DA. This is available from: http://cvs.zope.org/*checkout*/Products/DCOracle2/test/test_zopeda.py An example of how to use it (for ZOracleDA in this case) is available from: http://cvs.zope.org/*checkout*/Products/DCOracle2/test/test_zoracleda_basic… There are instructions for running it at the bottom of: http://cvs.zope.org/*checkout*/Products/DCOracle2/README I'd be very interested if users of the other database adapters could see how this does against their products. If anyone wants help to do this, please mail me off list. If this proves useful, I'd like to check it into the core Zope CVS, what do other people think? I do have some questions, though. DA's return a Shared.DC.ZRDB.TM subclass when they are called, this has lots of transaction-ish methods. I currently check that these are there, but does anyone know how I could check that they do what they're supposed to? Also, if anyone can see any methods on any objects that I'm not currently testing, but that should be tested, please let me know! cheers, Chris

1 0

Re: unicode and structured text (was Re: unicode oddities )
by Andrey Lebedev 31 Oct '03

31 Oct '03

On Fri, Oct 31, 2003 at 04:40:53PM +0100, Godefroid Chapelle wrote: > At 16:20 31/10/2003, H. Turgut Uyar wrote: > >>>There is a patch for structured text that fixes this behaviour. You can > >>>find it at: http://zope.org/Members/kedder/stx_18n_patch > >>I just downloaded it, applied it to my french setup and it works :-) > >>Thanks a lot. > >>Did you send it to the zope-dev list, it could make a lot of sense in > >>2.7... if it is still time. > > > >I agree. But it's not my patch, I thought the original author should do > >the contacting. Actually, it was announced on the zope.org site several > >months ago so I thought the zope developers would have heard about it. > > > >-- Turgut > > Hi Andrey, > > how secure do you feel about proposing to integrate your structured text > i18n patch in 2.7 ? With pleasure, this patch was installed on our copany's production server for half a year and worked fine. Lots of people had reported the same. However i feel it needs a little bit more testing, especially with zwiki and plone. I had one report about problems with plone, but i didn't managed to reproduce it on my system with the latest versions... The problem was an exception "ASCII decoding error: ordinal not in range(128)", when he tried to edit some properties in plone document. Maybe it was an already fixed plone bug, but who knows... If you know a good way to attract testing forces to the patch, please suggest:) Another thing a want to do before merging with zope is to consult with zope gurus out the right way to do the trick: Current (0.9.9) version of patch makes StructuredText to return unicode object, the earlier one (0.9.0) used to return plain utf-8 encoded string. I thought (and think) it is better to return a unicode object, since zope publisher could convert it then to any other encoding. However the guy with problem mentioned above reported, that the problem disappeared when he switched to 0.9.0 patch. So, if someone has any thoughts about it, please tell (i hope i've described clearly :) ). and BTW, what is the best way to propose a patch? > > BTW a lot of thanks for your solution to a problem that was biting my users. I'm always glad to hear it. Thanks :) -- Andrey Lebedev aka -.- . -.. -.. . .-. Software engineer UAB Mikromarketingas (http://micro.lt) Homepage: http://micro.lt/~andrey/ Jabber ID: kedder(a)jabber.ru

1 0

ThreadLock module?
by Chris Withers 31 Oct '03

31 Oct '03

Hi all, Anyone know what the difference is between Zope's ThreadLock module and the standard python Lock objects from the threading module? Chris

2 1

Re: [Zope-CMF] Better MemberData search for CMF
by Florent Guillaume 31 Oct '03

31 Oct '03

[The main discussion is focused on CMF, please keep zope-cmf(a)zope.org in the Cc.] Basically we need a search API. I'm Cc-ing zope-dev, exuserfolder-devel and plone-developers (for GRUF) because we're talking about user folders. The last part is especially of interest to you guys. Jens wrote: > Florent Wrote: > > Currently CMF's MemberDataTool has > > searchMemberData(search_param, search_term, attributes=()) > > but it can only do a search on one attribute. It returns a list of > > dictionaries. > > > > CMFLDAP's MemberDataTool inherits the one from CMF, and so actually > > does the search only in cached members. This is a big problem for me. > > The way it is done in CMFLDAP stems from how the LDAPUserFolder reacts > to calls such as getUsers, which will retrieve all users. Calls like > that are inappropriate and even dangerous for any user folder that has > a storage with large numbers of records. Zope (and possibly the storage > backend used by the user folder) will come to a standstill if all of a > sudden thousands of records come flooding back and they all need real > Zope user objects created for them. > > The LDAPUserFolder has a notion of caching users to avoid the speed > penalty caused by having to go to LDAP. I made the conscious decision > to implement getUsers in a way that will only look at the > currently-cached users. Anything else is potentially disruptive for the > running Zope or the LDAP backend. Yes I understand the reasons for this behavior. Still it's painful, and is a proof we need a search API. > > Plone (in MembershipTool) has > > searchForMembers(**kw) > > that could search on arbitrary attributes but actually only does it on > > name, email, roles, and last_login_time. It returns a list of user > > objects. > > > > CMFLDAP's PloneLDAPMembershipTool seems to be more intelligent than > > its MemberDataTool and do the full LDAP search, but I'm not sure. > > The PloneLDAPMembershipTool's searchForMembers is different in response > to specific Plone needs. In my opinion it still sucks really bad. If > you look at the code in searchForMembers in the standard Plone > membership tool you will see that it does the "dangerous" thing of just > grabbing all users from the user folder and then looking at each user > to see if the search criteria fit. > > There's another item that makes searching members in a CMF-based portal > more complicated: Users that you find in the user folder are not > necessarily members, even if the user seems to have the Member role. > You always end up having to introspect the MemberData tool to see if it > has a member data wrapper with the same ID. Yeah maybe we also need a MembershipTool.hasMember() method ? It's better than doing 'id in mtool.listMemberIds()' ... > > I'd like to propose a standardized API on which we can agree for the > > future: > > MemberDataTool: > > searchForMembers(mapping, maybe_some_options=None, **kw) > > It would search on all the keys of mapping+kw. > > The options would be there to ask for a substring or exact match. To > > be decided later. > > I'd like it to return a list of users, but this may be problematic > > from a security point of view. What do you think? Otherwise we could > > make it take an attributes=('email', 'fullname') args, and return a > > dict with at least the specified attributes. > > If you want to go the "sequence of dictionaries" route then the > properties as defined on the MemberData Tool should be looked up to > define a set of standard attributes to return, meaning attributes above > and beyond the user name. Yes. > > A side problem is that this method will have to have knowledge of how > > to do a search in the user folder. And there are lots of those, with > > nowhere an standardized API in sight to do search either :-( (actually > > I don't know any that can do a search appart from LDAPUserFolder). > > Maybe we could take the oportunity to define one ? Searching for > > userids, roles, groups (for me), is a prerequisite for me. > > A standard API for such searches on the user folders would be a > prerequisite for any of this so that the user folder, which is the only > link in this chain that really knows how to make the search efficient, > can do so. That would completely eliminate that nasty pattern of "I > will grab all users myself and then look at each user object". I agree, so I'd like to propose an API for this too. I haven't thought about it much. LDAPUserFolder has findUser(search_param, search_term, attrs=[]) but it only searches one one term. So I propose: searchUsers(mapping, attributes=(), other_options=..., **kw) it would work in the same manner as searchForMembers above. As above, do we make it return a sequence of user objects or a sequence of dictionaries ? In any case we'll need a way to only return user ids. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com

2 1

Zope 2.6+ pyton 2.3 ? and "Bad Call" on zope 2.6.2/python 2.1.3 with profiling turned on.
by Romain Slootmaekers 31 Oct '03

31 Oct '03

Yo, I have an elaborate piece of python code that works fine, but with profiling turned on, it barfs a "Bad Call" message. When google-ing for a solution, the only thing I could find was a http://mail.python.org/pipermail/python-bugs-list/2003-June/018510.html There's a follow up stating it's "already fixed", and does not occur in Python 2.2.x and beyond. So now my questions are: - how difficult is it to get a zope 2.6.2 (or 2.7) working with a python 2.2.x or 2.3. on a windows platform? (I read up on the changes between 2.6 and 2.7 and it does not seem to change python version.) - I believe there's a concensus that the next major 2.X release should jump immediately 2.3, but is there a timeline ? - or is there a workaround/solution to the "Bad Call" problem? This all to see if I should invest time in getting a 2.6 or 2.7 +python 2.3 up and running or I should do my own time measurements/profiling effort. TIA, Romain Slootmaekers.

4 5