Re: [Zope-dev] Defining Zope 3.
Martijn Faassen wrote: Hey Martin, Martin Aspeli wrote: [snip] Sigh... this discussion is just really difficult. I don't really understand what the problem is here, or why it's indicative of what's wrong with this community, but then I'm pretty lost in concepts and names at this stage. I think you're reading way too much into what I wrote though. I just meant thing using the Zope Toolkit but adding more stuff, e.g. an app server project or a shared management UI project. The difference is I think was that I'm not talking about just code; a KGS is just a list of versions. I'm talking about code and documentation and a presentation of this code as a whole that people can learn about and play with. The notion that it's just enough for Zope 3 to be pieces of code is part of what led me to Grok. If the notion of Zope 3 can be limited to just a greater set of packages where compatibility is tested, it's not really much of a project to speak of. That's fine, we have other projects like Grok that do care, but I'll stop worrying about it. sure, i understand what you're saying here. it'd be great if some set of folks who are using the full Z3 app server platform decided to step up, create a website, refine the branding, and just generally breathe life into the project. but, until someone does, we have a weird muddled situation where nobody except the people who are regulars on this mailing list has any idea what is going on with this Zope thing. me, personally, i don't use the Z3 app server platform, so i'm not going to be one of the people who steps up to take charge of it's public face. and, frankly, i don't really care one way or the other whether or not anybody else does it. but you DO seem to care, martijn; you'd like to see that platform get the love, attention, and branding that it deserves. that's great. but i suggest you'd have more success in that effort if you said things like: Hey, all you people out there using the Zope 3 app server thingy... you realize you have a branding problem, right? Now is a perfect time to revisit your platform. Maybe some folks should get together, come up with a catchy name (Rob Miller already suggested 'Zapp'... ;-) , and build a website with some documentation... whaddaya say? instead of: The whole idea of whatever-Zope 3-is-designated-as just being a 'larger KGS' strikes me as strange. Frankly it strikes me as indicative of what's wrong with this community. of course, there are no guarantees that you're going to get any takers no matter HOW you approach this. but that's life, IMO... if nobody steps up to do what needs to be done, well, there you are. -r ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Defining Zope 3.
Gary Poster wrote: This message seems like a reasonable start to me: Zope 3 has become focused on supporting frameworks and applications, rather than trying to be one itself. It is now called the Zope Toolkit. Parts of it are used by Zope 2, Plone, Grok, Repoze.bfg, and by many other different applications and frameworks. indeed, this seems to me a very nice message. short, pretty much accurate w/o delving too much into the mind-numbing details. yes, there may be some folks out there using the full Z3KGS as an app server, but those are the foks that already understand what's going on. they're just another community of people making good use of the Zope Toolkit. who knows, maybe the app-server-now-known-as-the-full-Z3KGS will grow in popularity to the point where it decides to rebrand itself as a groovy new platform. i'd recommend the name Zapp. ;) -r ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five registerPackage results in unresolved ConflictError
Philipp von Weitershausen wrote: Believe something very very rotten in Five's registerPackage was fixed by Rocky in r72986 [1]. As far as I can tell this was never merged to the 1.4 branch, but I could we wrong. i can confirm that this seems to be helping. there's an easier way to generate the error that Sasha is seeing... you can reliably reproduce it on Zope 2.9.x w/ Five 1.4 just by starting a zeo server with no Data.fs file, and then trying to connect with a zeo client. if you have any five:registerPackage tags, the first connection will _always_ fail with a ConflictError. subsequent connections will work, but the initial one will fail. (we've had to put a './zopectl run do_nothing.py' steps into our build code... :-P) anyway, the error is not happening with Zope 2.10 and Five 1.5.6. glad to know it's been resolved. :-) -r [1] http://svn.zope.org/?rev=72986view=rev Sasha Vincic wrote: Forgot to say that this is Zope 2.9.8, Five 1.4 branch from svn, Plone 2.5.5 /Sasha On Fri, May 16, 2008 at 12:03 PM, Sasha Vincic [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi On a server we have a ZEO server with 6 clients. When we start/restart the server we often get on random instance an AttributeError @@plone and all other browser pages. I have tracked it down to a ConflictError when installing Five on startup. See traceback bellow. To solve this I tried to set enable-product-installation = off to all except one instance but I still got errors. For now we restart the broken instances until they work, I have tried to set sleeping times up to couple seconds between the instances but it didn't make any difference. Five fails when it tries to execute the registerPackage in zcml files. Not the same product every time. First I thought it didn't respect the enable-product-instalation but that is checked in App.Product.initializeProduct method. So I played in fiveconfigure.py with transaction.savepoint() but no success but if I manually check App.Product.doInstall like in the diff below Now my question is if this is correct solution for the problem or will it have other side effects that I am not aware of? How do I write tests for an ConflicError during startup? /Sasha Index: fiveconfigure.py === --- fiveconfigure.py(revision 86781) +++ fiveconfigure.py(working copy) @@ -23,7 +23,7 @@ import warnings import App.config -from App.Product import initializeProduct +from App.Product import initializeProduct, doInstall from App.ProductContext import ProductContext import Products from zLOG import LOG, ERROR
[Zope-dev] Re: Zope without Zope
Lennart Regebro wrote: On Nov 16, 2007 11:41 AM, Lennart Regebro [EMAIL PROTECTED] wrote: On Nov 16, 2007 3:38 AM, Martin Aspeli [EMAIL PROTECTED] wrote: Help appreciated! Well, I suggest you forget about ZCML and try to use the CA directly from Python. The Pylons people would probably appreciate the lack of XML anyway. :) i'd also recommend this. i've actually been working on a pylons app that uses zope.component, it works like a dream. zope.component brings in a total of 6 eggs, IIRC. if you really want zcml-like separation of config and code, then put your python configuration declarations in a separate module. this not only Just Works(tm), but i think lennart's point about not scaring people away w/ an XML-based config language is a huge one. -r ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
Philipp von Weitershausen wrote: whit wrote: Martin Aspeli wrote: Philipp von Weitershausen wrote: This is awesome, and by that I don't mean the fact that we have a plone buildout, but that we actually have Zope 2 recipes for buildout. I hope they can be moved to svn.zope.org for further development to benefit the whole Zope 2 community. I believe this is just a matter of contrib agreements being sorted out (Hanno?). I guess I need to get mine sorted out as well if I'm going to keep working on this when it moves... :-/ I also see that workingenv was abandoned. That's very good to hear because buildout has a lot of machinery for installing eggs already, it would just've been duplicated with workingenv... is there some advantage to the way that buildout handles eggs over workingenv. as I understand it, workingenv *only* handles python setup and does that well and transparently. The point is that buildout *already* handles eggs. There's really no point for having an extra layer on top of buildout. The zc.recipe.egg recipe can install any egg (as a development one or not) in an automated fashion, which is exactly what you'd want from a buildout. honestly, it seems to me that buildout tries to do too much. it's trying to handle both repeatable deployment recipes AND providing a sandbox within which to run things. there may not be a point to having an extra layer on top of buildout, but buildout sure does seem to me a bit heavy if all i want is a sandbox. so now i have to learn the workingenv way if i just need a sandbox, but i have to learn the buildout way if i also want repeatable deployments? Workingenv made it more complex than it needed to be (or buildout as stated before, I don't mind using zc.buildout, but I don't want to have to learn zc.buildout to use it meaningfully in my existing setup. If a buildout recipes could be executed by themselves(like buildout-zope2, buildout-deliverance, buildout-squid) as well as by aggregated recipes. This would make buildout a killer tool inside my workingenv rather than a choice I had to make between two technologies. As said already, I think once you've got buildout, there's no need for workingen, except if you think that Zope stinks ;) this is shortsighted, IMO. i know zope quite well, but i bounced off of buildout b/c it required too much knowledge to even get started. i think it's much more likely that people from the greater python community will pick up and start using workingenv than they will zc.buildout. personally, i like chris mcdonough's approach with his buildit package. it does two things: - it retrieves files from anywhere on the 'net (cvs, svn, tarball, whatever) and puts them where you want them on your target machine(s) - it launches external scripts that then perform whatever final configuration you may want to perform. buildit is also recipe driven, and it's smart enough to pick up where it left off on a previous run, a'la make. i'd guess that you could use buildit and workingenv to accomplish pretty much everything you can do w/ zc.buildout, and you wouldn't have to bend your brain so much to do so. -r ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
Martin Aspeli wrote: Rob Miller wrote: honestly, it seems to me that buildout tries to do too much. it's trying to handle both repeatable deployment recipes AND providing a sandbox within which to run things. there may not be a point to having an extra layer on top of buildout, but buildout sure does seem to me a bit heavy if all i want is a sandbox. so now i have to learn the workingenv way if i just need a sandbox, but i have to learn the buildout way if i also want repeatable deployments? Potentially. But I find it kind of reassuring to have a well-defined list of which eggs are part of my special environment i.e. the one tied to my instance. to find this i simply look in /path/to/workingenv/lib/python2.4. As said already, I think once you've got buildout, there's no need for workingen, except if you think that Zope stinks ;) this is shortsighted, IMO. i know zope quite well, but i bounced off of buildout b/c it required too much knowledge to even get started. i think it's much more likely that people from the greater python community will pick up and start using workingenv than they will zc.buildout. Again, I think the two are orthogonal. orthogonal, but with overlap. And honestly, I found zc.buildout pretty easy to understand. I resisted it for a while, it seems liked it *should* be complex, and I won't pretend to understand how it manages eggs in any detail, but I don't think it matters. Look at http://dev.plone.org/plone/browser/ploneout/trunk/buildout.cfg - I find that pretty self-explanatory. I tried to document how it works at a high level and how you may use it here http://dev.plone.org/plone/browser/ploneout/trunk/README.txt. And writing a new recipe is as simple as this: http://dev.plone.org/plone/browser/ploneout/trunk/src/z2c.recipe.zope2checkout/src/z2c/recipe/zope2checkout/__init__.py All that is plain python code, the only thing you need to understand about buildout is that it has a dict-like object called 'options' which reflects the options in the current part's section in buildout.cfg, and a higher level dict-like object called 'buildout' which has the options for all the parts (so buildout['foo'] are the options for part [foo] in buidout.cfg). Each part is associated with a recipie. Recipies are ordered. personally, i like chris mcdonough's approach with his buildit package. it does two things: - it retrieves files from anywhere on the 'net (cvs, svn, tarball, whatever) and puts them where you want them on your target machine(s) You can do that quite easily with buildout as well. I would like to make a more generic recipe for retrieving tarballs for e.g. zope installation, and I think it'd be as hard as figuring out which python function to use to download something. i have no doubt that zc.buildout will do everything that buildit will do, and probably much more. but i like simple. and for me, having something light like workingenv to manage my sandbox, and a library like buildit for putting files into those sandboxes feels simple. - it launches external scripts that then perform whatever final configuration you may want to perform. Again, if you want a recipe to do that, it's trivial to write (10 lines of code?). Instead of an external script, though, I would probably find it easier to write that as a buildout recipe in python. the script could of course be python as well. buildit is also recipe driven, and it's smart enough to pick up where it left off on a previous run, a'la make. i'd guess that you could use buildit and workingenv to accomplish pretty much everything you can do w/ zc.buildout, and you wouldn't have to bend your brain so much to do so. I'm just struggling to see why it's so hard to figure out how buildout works. Perhaps it just fits my brain. But honestly, once Hanno showed me his initial steps with ploneout and I'd taken ten minutes with pdb inside the __init__() and install() functions (the only two...) in his recipe the pieces fitted together in my head almost instantly. your efforts to figure something out and then document will have a major impact on people understanding this, as per usual. but still, something about it just feels heavy. the idea of having two separate tools, each of which does one thing well, working together to solve a problem suits my sensibilities more than having one more monolithic tool. luckily, we don't really have to convince each other of anything, here. it's entirely possible to have zc.buildout recipes for installing Zope and Plone as well as buildit / workingenv recipes for the same purpose. -r ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZopeVersionControl bug
is there a current maintainer or development process for ZopeVersionControl?
there's been a little bit of activity lately, but it's still in CVS.
in any event, CMFEditions (a versioning system for Plone) depends on ZVC, and
it seems that some recent changes to Zope's DateTime implementation have
caused a ZVC bug to come to the surface. dorneles has recently improved the
ISO8601 support in the DateTime module (http://tinyurl.com/y9weck). one of
the results is that DateTime('1') now is interpreted similarly to DateTime(1),
whereas before it would raise an error.
in ZVC's Repository.getVersionOfResource() method (http://tinyurl.com/yab2xw),
a selector is passed in, which the method will try to use in a number of ways
before deciding that there's no matching version to return. the final test
looks like this:
try: date = DateTime(selector)
except:
raise VersionControlError(
'Invalid version selector: %s' % selector
)
else:
... RETRIEVE BY TIMESTAMP HERE
thus the change in DateTime behaviour means if the selector is a string
representation of an integer, it formerly would have been rejected as invalid,
but now will be considered a timestamp lookup. since version ids are
commonly string representations of integers, this can be a bit of a problem.
i'm not sure whether the DateTime behaviour should be reverted, or if there
should be a change in ZVC. and i'm also not sure what's going on w/ ZVC's
maintenance... are there any plans to bring it over to subversion? i'm happy
to commit a fix, if someone can point me in the right direction.
thx,
-r
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: wsgi/paste pipelines in Zope 2 or 3?
Sidnei da Silva wrote: On Thu, Sep 28, 2006 at 01:11:05PM -0400, Brad Clements wrote: | I've been doing a lot of work with Paste in the past year, cutting down on my | deployments of Zope. | | Now I'm taking a new look at Zope 3 and Zope 2, and wondering if it's possible to | use paste pipeline/filter in either version of Zope. I've looked at | | http://cheeseshop.python.org/pypi/zope.paste | | and | | http://awkly.org/archive/zopepaste-wsgi-applications-in-zope-3-using-pastedeploy/ | | But what I need is not just a wsgi application hosted in Zope, but rather, a wsgi | filter that can intercept the call chain during traversal. | | Has anyone else encountered this need or have thoughts about it? Hi Brad, The fine folks from The Open Planning Project /me grins. most of it is the work of one fine folk, ian bicking. are developing 'topp.wsgi', which is pretty much what you're looking for. it's actually 'topp.zwsgi'. anonymous svn available here: https://svn.openplans.org/svn/topp.zwsgi/ browseable interface here: https://svn.openplans.org/cgi-bin/viewcvs.cgi/topp.zwsgi/ You can find them in #openplans on irc.freenode.net this is true, yes... please be aware, though, that this stuff is nascent, and our support time is limited. we can help self-motivated folks who are digging through the code and asking intelligent questions, but we're not yet to a point where we can do a lot of hand-holding. we do plan on using it within our own offerings, however, and all of our code will be available (in the same svn repo linked above), so i suspect this story will be improved in the coming months. -r ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Re: [Checkins] SVN: Zope/branches/2.9/lib/python/ Replace bulk of uses of 'zLOG' with equivalent Python 'logging' module usage.
On Mon, 26 Jun 2006 12:59:49 -0400, Tres Seaver wrote:
Andreas Jung wrote:
--On 25. Juni 2006 16:32:04 +0200 Stefan H. Holek [EMAIL PROTECTED]
wrote:
This, BTW, breaks CMF 1.5 on Zope 2.9. Not sure I/you should care
though ;-)
Traceback (most recent call last):
File /home/stefan/autotest/temp/python24-zope29-cmf15/Products/
CMFActionIcons/__init__.py, line 19, in ?
from Products.CMFCore.DirectoryView import registerDirectory
File /home/stefan/autotest/temp/python24-zope29-cmf15/Products/
CMFCore/__init__.py, line 21, in ?
import MembershipTool, WorkflowTool, CatalogTool, DiscussionTool
File /home/stefan/autotest/temp/python24-zope29-cmf15/Products/
CMFCore/CatalogTool.py, line 23, in ?
from Products.ZCatalog.ZCatalog import LOG
ImportError: cannot import name LOG
Tres,
you replace all 'LOG' vars with 'logger'. Is there a reason for this
replacement? We've been using LOG through out the complete Z2 core..we
should remain consistent in some way.
Hmm, the API of the logger objects is not consisistent with the old log
objects. I don't know why CMF is importing that name from the catalog,
but I guess we need to leave it there for BBB.
as it turns out, ZCatalog originally had from zLOG import LOG on line 37
but then redefined in a LOG = logging.getLogger('Zope.ZCatalog')
statement on line 47; when other products import from ZCatalog it was the
second one they were getting, not the first.
i changed tres's BBB fix to reflect the actual (if strange) former
behaviour.
-r
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Flood of deprecation warnings...
Chris Withers wrote: Both core zope and Plone spew forth in their default state. the deprecation warnings in Plone annoy me to no end. unfortunately, though, Plone (thus far) has chosen to straddle Zope release. i can't fix the deprecation warnings that Plone 2.5 generates with Zope 2.9, for instance, because that would cause Plone to no longer work w/ the Zope 2.8 series. there is talk of having Plone 3 only support Zope 2.10; if this happens, then i suspect we'll no longer see deprecation warnings in a default Plone setup. -r ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope2.8.7] with Five 1.0 or Five 1.2
Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27 Mar 2006, at 11:55, Philipp von Weitershausen wrote: Andreas Jung wrote: Zope 2.8 ships/shipped with Five 1.0 which is very old and no longer actively maintained. Most ppl doing currently development with Zope 2.8 are using Five 1.2. Should we upgrade the Five version in Zope 2.8 to Five 1.2 to make their lives a bit easier? There is possibly a compatiblity problem involved and it is against the general rule for major upgrades of a package or product for a minor Zope release..I have no opinion on this issue...I just had this thought I would be in favour of such a move, because as a Five developer I'm biased (so my vote doesn't really count, either) +1 Currently, CMF 1.6 depends on Zope = 2.8.5 and Five 1.2. I'd much rather simplify that requirement to Zope = 2.8.7.. +1 here as well. Plone 2.5 depends on CMF 1.6 and thus has the same dependency issue. even worse, it supports both Zope 2.8 and Zope 2.9, so in some cases (Zope 2.8 setups) installing an additional version of Five is necessary, but in other cases (Z2.9) installing that version of Five will break everything. -r ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Re: Two visions
On Thu, 02 Mar 2006 09:43:03 -0330, Rocky Burt wrote: On Tue, 2006-28-02 at 13:21 +0100, Martijn Faassen wrote: Philipp von Weitershausen wrote: [snip] I would vote for spelling out Zed (which would also be a little easier to google but might create trademark problems). The namespace package could either be 'z' or 'zed'. Then again, I really should take Jim's side and stay out of naming decisions. Let's please not have a naming discussion again. I think renaming Zope 3 is really bad marketing myself and naming discussions mostly a waste of time... As I sit here spending sooo much time reading this thread yes, it's a big'un alright... 1) The Zope 3 name and brand is a marketing disaster (from my perspective) -- to be honest there's really no way I could see this actually getting worse by coming up with a new name. How many times in the #plone channel do we get asked, Does Plone run on Zope 3.1/3.2? or, When will Plone run on Zope 3.2 to which we say no to the first question and dunno to the second question. +100. it's a confusing mess to anyone who isn't spending as much time as we all are reading this stuff every day. come to think of it, it's a confusing mess to us, too. If we started treating zope 3 as just a framework and put energies back into maintaing/refactoring/beautifying zope2 as an application server that uses that framework at its core (this is essentially what zope 2.8+ is working towards with Five IMHO) then this could help several ways: 1) we stop spending time reproducing zope2 app server functionality in zope3 2) we stop building more into zope2 as a framework (i think this is pretty much already happening) i agree with this sentiment, although i do recognize that there are folks who are currently using zope3 as an app-server, and who (understandably) don't want to have anything to do w/ anything zope2 related, ever again. Anyway, this still keeps things very confusing from a naming perspective (mostly for new adopters). So having said all of that, I am actually +1 on Jim's proposal #2. What I see from that (someone correct me if I'm wrong) is the following: 1) rename zope 3 the framework as Z or zopelib or Zed or something sensical that doesn't confuse the early adopter's conquest of trying to figure out which zope to start with 2) Make zope 2 the application server acquire the name zope once again and be the only app server. This could only work (from a new adopter's perspective) if either the application server is given a new name or given a version number higher than 3. i support this idea as well, but i think we have to recognize that there will be some parallel app-server-ness happening for a while, until z2 becomes so thin that we have achieved complete convergence btn the z2/five-based and the z3-based app server platforms that are already being used. -r ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Two visions
Stefane Fermigier wrote: Strange how (most of) the Plone people seem to be so quick in willing to sacrifice the Zope brand :( um, if you reread what i said, and what i think rocky is trying to say, i'm in favor of _keeping_ the zope brand for the app server, which is what zope has always been, and what plone runs (and will continue to run) on top of. strange how stefane seems to be so quick to write incendiary posts w/o any real content in them... -r ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Member tools refactoring (Was: Better MemberData search for CMF)
another possible angle on all of this is CMFMember, which replaces the default memberdata tool with one that provides Archetypes-based memberdata objects. this already provides some (most?) of the functionality you're suggesting in the userdirectory tool, i believe. i'm pretty sure that Archetypes and CMFMember are still Plone-specific for now, but i thought i heard rumblings that Archetypes might be considered to be rolled directly into the CMF... if not it could probably be made to at least work w/ CMF-sans-Plone. -r Lennart Regebro wrote: 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 ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
