Re: [Zope-dev] FWIW, ZCVSMixin now at 0.0.2... and rising. ;-)
Steve Spicklemire wrote: I've not heard any comments about the usefulness of this concept... am I barking up the wrong tree to get version control of zope objects? Does someone know of a better way? Steve, this has been my fondest hope for about three months now. Now, if I could also get it to do through-the-web XML (DocBook) editing and rendering, I'd have a complete end-to-end document management system. Particularly if it preserved accountability, like Jonothan was mentioning. I'll be testing this tommorow, and doing my best to get this to do unnatural things with XMLWidgets and DocBookDocument. Many thanks, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] eat our own unsupported dog food
Michel Pelletier wrote: There is a recent need for us to install ZDiscussions on Zope.org. I have verified that 0.1.0 works with 2.1.6, but I can't seem to d/l 0.2.0. The author of said software is not available, any one know the status on ZDiscussions? Has any one tweaked it? I found this: http://www.zope.org/Members/BwanaZulia/ZUBB/ HTH, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package descriptions
ethan mindlace fremen wrote: Michael Bernstein wrote: Please change the page so both the title and the description have the same background color, but that the color is alternated between grey and white for odd and even Products. Ok, well, I've given that a try. Some people think I should do it some other way. If you feel strongly about it, email [EMAIL PROTECTED] Thanks, that's a *lot* more legible (I do feel strongly about it). What other ways are people asking for? It also shows the most recently edited products first, and sorting by anything or requesting more Member products hides all Digital Creations stuff. Yeah, that's pretty slick. It occurs to me that the same layout should be used for the How-To's page. More Products work is on the way in the medium-term future. I would still really appreciate it if people would change their products page so that the first line is a plain text summary of their product. I have HTML quoted everything, which makes the formatting better, but some descriptions are still less than usefull. Perhaps a 'short_description' property could be added to the Product, and it would default to 'first line' only if that property was blank. Thanks for your help, You're welcome. Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Membership and Local Roles
I posted this to the PTK list on Friday, but didn't get any responses
over the weekend, so I'm reposting here.
I feel that a barrier to Loginmanager and Membership becoming more
generally usable for site builders is it's current lack of support for
local roles. Specifically, members do not show up in the local roles
screen (manage_listLocalRoles) user list.
Through the magic of grep and find, I think I've identified the relevant
sections of code in Zope that need to be duplicated in Membership (or
maybe in LoginManager).
First I tracked down what seems to be the relevant section in
/lib/python/AccessControl/Role.py, in the section labeled 'Local roles
support':
def get_valid_userids(self):
item=self
dict={}
while 1:
if hasattr(aq_base(item), 'acl_users') and \
hasattr(item.acl_users, 'user_names'):
for name in item.acl_users.user_names():
dict[name]=1
if not hasattr(item, 'aq_parent'):
break
item=item.aq_parent
keys=dict.keys()
keys.sort()
return keys
Then I tracked down the user_names attribute to
/lib/python/AccessControl/User.py, in the section labeled 'Private
UserFolder
object interface':
def user_names(self):
return self.getUserNames()
Well, that wasn't very helpful. searching a bit more and I find:
def getUserNames(self):
"""Return a list of usernames"""
names=self.data.keys()
names.sort()
return names
Experimenting a bit, I find that a normal user folder object responds to
an /acl_users/user_names URL with an error, but does respond to an
/acl_users/getUserNames URL with a list of user names.
And now I'm stuck. I *think* that LoginManager needs a getUserNames
method that cycles through the available User Sources and grabs a list
of
names from each, concatenating them into one big list to return. I'll
settle for some code that has the User Source name hard-wired in,
though.
However, IANAC (I Am Not A Coder), and I don't know how to do this. If
anyone can offer a cut-and-paste set of instructions to add this into
LoginManager or Membership, it would be greatly appreciated.
If I've missed something obvious or misunderstood the problem, please
tell me that too.
Thanks,
Michael Bernstein.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Membership and Local Roles
Steve Alexander wrote: Michael Bernstein wrote: I posted this to the PTK list on Friday, but didn't get any responses over the weekend, so I'm reposting here. I feel that a barrier to Loginmanager and Membership becoming more generally usable for site builders is it's current lack of support for local roles. Specifically, members do not show up in the local roles screen (manage_listLocalRoles) user list. Through the magic of grep and find, I think I've identified the relevant sections of code in Zope that need to be duplicated in Membership (or maybe in LoginManager). I think you've found out why local roles don't work. Congratulations on a successful code hunting mission :-) I *think* I've created a getUserNames python method that returns the appropriate results: Parameter list: self Body: user_ids=self.UserSource.getPersistentItemIDs() names=[] for i in user_ids: names.append(self.getItem(i)) return names I basically copied the Membership getMembers python method for this. Guess what? It still doesn't work. I don't understand the differences between the code I pasted above and the code on the original getUserNames method (from : def getUserNames(self): """Return a list of usernames""" names=self.data.keys() names.sort() return names Can anyone tell me what I need to fix? Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Membership and Local Roles
Michael Bernstein wrote: Steve Alexander wrote: Michael Bernstein wrote: I posted this to the PTK list on Friday, but didn't get any responses over the weekend, so I'm reposting here. I feel that a barrier to Loginmanager and Membership becoming more generally usable for site builders is it's current lack of support for local roles. Specifically, members do not show up in the local roles screen (manage_listLocalRoles) user list. Through the magic of grep and find, I think I've identified the relevant sections of code in Zope that need to be duplicated in Membership (or maybe in LoginManager). I think you've found out why local roles don't work. Congratulations on a successful code hunting mission :-) I *think* I've created a getUserNames python method that returns the appropriate results: I have made some more progress (of a sort). I added another Python Method to the LoginManager called user_names : Parameter list: self Body: return self.getUserNames() As far as i can see, this should be functionally equivalent to the user_names method in User.py: def user_names(self): return self.getUserNames() But it doesn't work. On the bright side, I've managed to break the manage_listLocalRoles local roles screen. This is the first time that I've had any interaction with the local roles screen, so I guess now I now I'm messing with the right stuff. The error message I get is: Error Type: AttributeError Error Value: __hash__ Here is the traceback: Traceback (innermost last): File /usr/local/zope/2-2-0/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /usr/local/zope/2-2-0/lib/python/ZPublisher/Publish.py, line 187, in publish File /usr/local/zope/2-2-0/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: ElementWithAttributes) File /usr/local/zope/2-2-0/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/local/zope/2-2-0/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: manage_listLocalRoles) File /usr/local/zope/2-2-0/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: manage_listLocalRoles) File /usr/local/zope/2-2-0/lib/python/App/special_dtml.py, line 121, in __call__ (Object: manage_listLocalRoles) File /usr/local/zope/2-2-0/lib/python/DocumentTemplate/DT_String.py, line 502, in __call__ (Object: manage_listLocalRoles) File /usr/local/zope/2-2-0/lib/python/DocumentTemplate/DT_In.py, line 630, in renderwob (Object: get_valid_userids) File /usr/local/zope/2-2-0/lib/python/AccessControl/Role.py, line 360, in get_valid_userids (Object: ElementWithAttributes) AttributeError: (see above) Any ideas? Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Returning a list of names from a Python Method
Michael Bernstein wrote: Does anyone on the list know how to change the getUserNames Python method to return a list of names instead of a list of objects? The code in question is this: user_ids=self.UserSource.getPersistentItemIDs() names=[] for i in user_ids: names.append(self.getItem(i)) return names Ok, I solved this little problem (and of course it looks obvious once I've done it): names=[] for i in user_ids: names.append(i) return names Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Membership and Local Roles
I figured out how to get this to work (finally). In the acl_users LM, add the following two Python methods: - getUserNames - Parameter List: self Body: user_ids=self.UserSource.getPersistentItemIDs() names=[] for i in user_ids: names.append(i) return names - user_names --- Parameter List: self Body: return self.getUserNames() And whatever users or members you've got that are stored persistently within the User Source will appear in the local roles screen (manage_listLocalRole). Preliminary tests show that local roles defined for LoginManager/Membership users work just as expected. Thanks to Bill Anderson for pointing out the difference between returning a list of objects and a list of names, which was the critical bug in the getUserNames method. Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Membership and Local Roles
Michael Bernstein wrote: Michael Bernstein wrote: I figured out how to get this to work (finally). In the acl_users LM, add the following two Python methods: Well, I discovered another problem: For some reason, when I create a PortalMembership member, add the two Python methods as I described earlier, and use the local roles screen to give them a role, they are subsequently authenticated regardless of whether their password is correct. Here's an example illustrating the bug: [snip example] This password problem is fixed with Bill Andersons new release of Membership 0.7.6, so the local roles fix now works generally. There is still a platform dependent password problem with Membership though. It affects Solaris and HPUX (possibly other unices) but not Linux, and has to do with the crypt module not being loaded correctly on those platforms, causing passwords to be encrypted omly part of the time. Here is the fix for local roles: First, the User Source needs to support a getUserNames method. This can be done two ways: You can add a Python method to the LoginManager named getUserNames that takes a 'self' parameter, and has the following body: user_ids=self.UserSource.getPersistentItemIDs() names=[] for i in user_ids: names.append(i) return names Or you can add the following code directly to the PersistentUserSource.py file, preferably right befor or after the getUsers method: def getUserNames(self): user_ids=self.getPersistentItemIDs() names=[] for i in user_ids: names.append(i) return names (I hope this will get included in future versions of Membership) Next we need to provide a user_names method in the LoginManager. Currently I only have a Python method to drop in to the LM. it takes a 'self' parameter, and has the following body if it's calling another Python method: return self.getUserNames() Or if you're calling the method in PersistentUserSource.py, it has this body: return self.UserSource.getUserNames() Note that this user_names method has some disadvantages, and it needs to be generalized to deal with multiple User Sources that aren't all named UserSource, and that may not all implement the getUserNames interface, and that may have duplicate user names in them. Suggestions on how to do this would be welcome. I hope that this little set of instructions helps others who are trying to integrate LM with the existing security interface and local roles. Comments, testing, and improvements would be welcomed. HTH, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Discussion Story Building Mediums
Chris Withers wrote: Michael Bernstein wrote: It seems to me that there is a potential 'bridge' between the mailing lists and the wikis - The mailing list archives! snip details I like this idea a lot :-) After some more thought, I realized that this really needs to be a three-way gateway betrween a mailing list, a 'blog, and a newsgroup. The 'blog is obviously the most different from the other two, as 'blogs usually excersize editorial control over the root items, but none (or little) over the ensuing discussion. This is markedly different from both mailing lists and newsgroups, where moderation is on all of the postings. Assuming that gets accomplished, this should take care of everyones 'discussion' needs, after which the trick is promoting certain things to permanent collaborative artefacts, like wikis. Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Trying to catch up - what are the best Zope tools today?
Itai Tavor wrote: Can anyone provide a quick rundown of the best choices for building a production site at this time? I'm going to need sessions, user registration and login, and the usual array of e-commerce pieces (products, carts, orders, payments...), with all data stored in SQL. As far as user registration and logins, LoginManager in conjunction with the Membership product seem to have reached a semi-stable implementation. It took me some serious skull-sweat to figure them out enough to do SMB authentication from a Solaris box off of a NT PDC, and some more to get LM to participate in the local roles machinery, but once I did, it's been working really well. I assume that creating an SQL UserSource won't be any more dificult. Good Luck. Warning: :-) The current membership product has not yet been re-integrated with the PTK, so the implementation (though stable) may have further architectural changes coming down the pipe. HTH, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns design questions
"Phillip J. Eby" wrote: At 09:49 PM 10/4/00 -0700, Michael Bernstein wrote: While I wouldn't say that there has been an actual 'paradigm shift' between the original RIPP presentation and ZPatterns, What's happened is that there's been a lot of "implementation shift". The goals of RIPP have never changed, but they are far from being all available in convenient form in the ZPatterns implementation of that model. [snip] - we've implemented less than half of RIPP at this point. Ok, That's what's been confusing me. I was thinking that at least some of the missing functionality was due to a change of goals. I'm sufficiently confused at this point to ask for an explanation (with definitions and a *simple* example) of your current thoughts on separating 'domain code' from 'implementation code', both of which still need to be separated from 'presentation code' (DTML interfaces), unless I'm mistaken. Please assume I'm asking a lot of 'why' questions along the way. Domain logic: methods which implement the basic behavior of an object, by manipulating its attributes and by calling methods on itself or other objects. (Including delegation to a Specialist, its own or another.) Presentation logic: "view" methods which implement user interface by displaying object attributes and/or the results of either presentation or domain methods, and "controller/view" methods which call domain logic methods and display results. Implementation logic: All of the code and objects contained in a Specialist which map between the domain model of an object and its physical storage implementation(s). This category can be further subdivided into data management implementation, and UI implementation. DM implementation deals with storing and retrieving objects and associated data, and firing off of implementation rules (e.g. ensure that all objects which meet such-and-such criteria are cataloged in catalog Foo). UI implementation deals with providing snippets suitable for use by collaborating classes and/or specialists. For example, [snip] How (and why) do you distinguish between UI implementation and presentation logic? Our current practice is to place both domain and presentation logic in ZClasses, [snip] Do domain and presentation logic methods go into the *same* ZClass, or separate ones (I realize that this may be a stupid question)? dropping down to ExternalMethods or Python bases for the ZClasses when domain logic requires things you can't do in DTML or PythonMethods. Domain and presentation logic are kept to seperate methods, so that domain logic methods can be re-used for XML-RPC or other programmatic interfaces. Presentation is usually done in a flexible way, relying upon UI implementation hooks where sensible. (Since objects under a specialist acquire from the specialist, it's easy to hook to a specialist-level utility method.) I understood what you were saying until the parentheses. Could you repeat that part in a different way? We have not yet released any actual frameworks based on ZPatterns, [snip] Isn't LoginManager a framework? I'm familiar with the convention of separating 'data' from 'business logic' from 'presentation logic', but this new four-way separation (storage, domain, implementation, UI) is confusing the heck out of me. There's really only three: Presentation, Domain, and Implementation. These largely correspond to Coad's UI, PD, and DM/SI, although we're also mixing UI snippets into the DM/SI part, simply because that's the locale for customization/integration. (In general, we do not assume that placing more than one kind of thing together as neighbors in the same place is a problem. It's what things *reference* that makes their implementation clean or dirty, not necessarily who their neighbors are in the Zope object tree.) Ok. That makes some more sense. (still working on the Zen, though) I know that both of you (Phillip and Ty) are very busy right now, but could you perhaps give us a few short installments? Starting at the beginning (wherever that is), of course. How's the above for a beginning? Great! Now I need a really stupid-simple example. Something that could have been implemented trivially by using Zope's built in objects, maybe a ZClass, and a bit of DTML, like a list of press releases, or a FAQ, or a company directory. Something *really* simple, so I can see how it's done with ZPatterns. Thanks, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] LoginManager ownership bug!
Jonas Juselius wrote: Another thing which I have tried to do, is to add support for local roles to the LoginManager. At first it looked rather simple, but then I realized that it wasn't really _that_ simple, and dropped it because I don't have time... It would however be nice to have local roles support in the LoginManager, as it would make it more complete. I am currently using Zope-2.2.1 (and Zope-2.2.2), ZPatterns-0-4-2a1 and LoginManager-0_8_7a1. I used Membership 0.7.6 on top of what you've got, and added support for local roles as detailed in this posting: http://lists.zope.org/pipermail/zope-dev/2000-September/007030.html This ought to give you the clues you need to add the neccessary getUserNames method to a SQL User Source, and make the LoginManager user_names modification as well. If you have any ideas on how to generalize the user_names method, I'd like to hear them. Let me know how it goes, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns design questions
Steve Spicklemire wrote: Ack.. of course I forgot to test creating new instances there was a snippet of code for editing and creating that didn't work with the new propertysheet stuff. I fixed it just now... so it really works. ;-) I didn't get a chance to play with this today, but I'll make time to do so tomorow. How easy would it be for you to write a step-by-step HowTo/WalkThrough of creating the example? I can edit it and flesh it out if you can write a bare-bones version. Thanks, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns design questions
Steve Spicklemire wrote: Again.. this is an embarrassingly trivial example.. but here it goes: [snip details] That's it. I can't imagine anything simpler. ;-) Really! Thanks, I'll be trying this out at work tomorrow. Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns design questions
Steve Spicklemire wrote: Ack.. sorry... I was making little changes last night to make sure the ZClass was completely consistent with my explaination, and to make sure I could start 'from scratch'. Ok, I just got through stepping through the walkthrough. Thanks! That *was* a really simple example. Perfect! I had a few comments: - You skipped over creating the Product in the Products folder. - Propertysheets: You don't expressly say that Shared needs to be a 'Common Instance Property Sheet'. - ToDoManager: I was initially confused as to where this needed to be created. I tried placing it directly in the Product as well as in the ZCLass before I tried placing it in a normal folder. Ok, moving forward, I had some questions about this approach to building applications: - What do I need to do to let users add ToDoManagers to their own folders without creating them from scratch? In other words, How do I turn ToDoManager into a product? - The term 'Specialist' implies (at least to me) that this object is overiding/replacing a 'Generalist' somewhere, but this does not seem to be the case here. Am I missing something? - I'm trying to reconcile PJE's methodology of Domain Logic, Presentation Logic, Data Management Implementation Logic, and User Interface Implementation Logic. Can you (or Phillip) label each of the DTML methods as to which category they fall into? And state why, even if it seems obvious? - How does this product (simple though it is) exemplify the RIPP approach? In other words, assume I'm asking annoying whiny two-year-old 'why?' questions after every declarative statement in the tutorial. Anyway, I'll try to synthesize all of the replies I get (if any) into a beginners 'Zen of ZPatterns' tutorial. Thanks again for such a simple example! Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns design questions
"Phillip J. Eby" wrote: How (and why) do you distinguish between UI implementation and presentation logic? Presentation logic lives with an object's class, and deals with what that object knows about presenting itself. UI implementation is "glue" presentation that lives in a Specialist for use by any object that needs to present UI related to objects of the kind the Specialist handles. The terms used here are "official" terminology with precise definitions, btw. I am just trying to answer your questions as best I know how. I'm not sure, but did you mean 'are not' in that last sentence? An example of presentation logic would be a method which displays a form to perform some action on the object. E.g., let's say we have a "Task" object with an "Assign To" form. Tasks are assigned to Assignees, but in a given application, there could be many possible kinds of Assignees and the means of selecting an Assignee is context-dependent. Thus, a Task's presentation logic cannot implement such a thing directly; it must ask the Assignees specialist for a code snippet (UI implementation) that displays an assignee selection sub-form within its "Assign To" form. [snip] The Assignees specialist is responsible for providing an appropriate UI implementation (hence the name) for this operation. It could provide a dropdown list, a type-in box with a button to pop up a search window that lets you search the employee directory, or any number of other possible implementations that would get the necessary data back to the assignment method once the form was submitted. We could include a simple implementation with our task management framework, and the application integrator would override it if needed for their situation. Thanks, this is starting to make a lot of sense WRT reusable frameworks. Here is where my 'Specialist/Generalist' confusion came from. It seems to me, that the simple implementation (you might also call it the default implementation) for the selector UI in your example should be contained in a 'Generalist' object that could be overridden by a 'Specialist'. This would help make crystal clear the line between Presentation Logic and Implementation UI, and would also serve as a useful starting point for creating the overriding methods in the 'Specialist' by the framework customizer. We have not yet released any actual frameworks based on ZPatterns, [snip] Isn't LoginManager a framework? Okay, you've got me there. I tend not to think of it that way, if only because there are many things less than satisfactory about its current state of implementation. For example, if we had it to do over again, I would re-work the internal API so that roles, domains, authentication, etc., could be controlled by plug-ins on the user sources. At that point there would be no need for different kinds of user sources, as they would all be fully generic. But anyway, I digress. In light of my own dificulties in adding SMB authentication to PersistentUserSouce.py, and Bill Andersons dificulties with password encryption on some Unices, I think that this would be a *very* worthwhile effort. Such a project might also give you the mandate to get DC to fix the Zope internal acl_users interfaces that were getting in your way. How large of a project would this be? Thanks for your patience in answering my questions. I think I'm getting a good understanding of this approach, but I'm still working on internalizing it. Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns design questions
Steve Spicklemire wrote: - How does this product (simple though it is) exemplify the RIPP approach? pje I'm not sure that you can say it *exemplifies* the RIPP pje approach, although it certainly goes along with that pje approach. My hesitation is mainly that it doesn't really pje show any of RIPP's major benefits, which are associated with pje framework re-use and integration. For that, you really need pje to have more than one kind of object, with some kind of pje collaboration taking place. Hmm.. can anyone thing of a good collaboration 'partner' for a simple ToDo list? If it's not too complex.. I'd be happy to add it. I've thought about this since yesterday, and the simplest kind of 'partner' that I can imagine for a 'ToDo', would be a 'Deliverable'. A deliverable would probably have a title, it's own 'Done' boolean property, and probably an optional DeliverableURL property. I'm not sure if it would need it's own 'Doer'. ToDo would need to be reworked so that it's 'Done' property could only be set if all associated Deliverables (if any) were also done (Steve McConnel (sp?) calls these 'binary milestones'). What do you think, is that simple enough? Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Better user management: Usership vs. Membership
Jonas Juselius wrote: Hello, I had a look at the Membership product, but I could not get it to work. It seems that the PortalMember ZClass in the PortalMembership Product inherits from _ZClass_for_LoginUser, which is no longer in the LoginManager... Were you trying to use Membership with a CVS verson of LoginManager? Membership 0.7.6 works with LM 0.8.7a and ZPatterns 0.4.1snap1. But actually I don't care... I tried to contact Bill about the Membership Prod, but he seems to be unreachable because his mail address doesn't work. Bill just got married, was in the middle of changing network providers, and his old provider screwed up their IP addressing (on his wedding day). He says that he'll be back up Thursday or Friday. I found many nice ideas in the Membership product, and I think it would really be a good idea to develop it further. Does anybody know about any recent developments or what the current status is? Is there going to be a new release soon, is anyone even working on the Membership product? Bill is currently working on re-integrating Membership with the PTK. I recently found a way of integrating Membership+LM with the local roles interface. I also modified my copy of Membership to authenticate off of an NT PDC via SMB from a Solaris box. Most LoginManager and Membership discussion happens on the Zope-PTK mailing list, not Zope-Dev. Cheers, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python and Perl scripts
Michel Pelletier wrote: Keep in mind also that we are moving towards a new architecture with "Documents" and "Templates" (ala HyperDOM). I think Scripts fits right in there: Documents, Templates and Scripts or Documents, Templates and Methods I tend to think of things as: Objects, Views (or Templates) and Blocks. The diference (for me) between a View and a Block is whether they are intended to be accessed directly by a client (browser). Blocks also tend to be reuseable in many views (I typically have a Block (DTML Method) called main_navigation, for example), and can be composed of other Blocks. Views like index_html may be reused, but usually through acquisition, not recomposition. The lines are fuzzy though, since I'm usually using the same types of objects (DTML Methods) for both Views and Blocks. Perhaps we need an object type that is not directly accessible from a client (but may only be called or rendered from other objects) in order to clarify the distinction. Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Meaning :-S
Chris Withers wrote: Ken Manheimer wrote: Huh. We're looking for something neutral, to connote code that runs in zope to do some business logic or similar effect. It should distinguish the language used to express the logic - perl vs python vs xslt, etc. I hate "script", but it occurs to me that the "-let" convention may be useful: Python Zopelet Perl Zopelet XSLT Zopelet Zope-specific, runs on the server, shows the implementation language, won't be confused with non-remotely-editable functions, methods, scripts, code in general. This is the first one with which i'm comfortable - but i may well have missed something. ...yeah, Zopelet means absolutely nothing, and will just add to confusion :-( Chris . o O ( what the hell is a Zopelet? ;-) I have to say that I don't like Zopelet either. I guess nobody else likes my 'Blocks' nomenclature: Python Blocks Perl Blocks DTML Blocks As I mentioned before, I tend to use DTML Methods in two contexts: - as Views on objects (Templates) - as building blocks for Views In one context (Views/Templates), the DTML method is meant to be accessed directly through the web. In the other context (Block), the DTML method is only ever accessed by a View. I would actually like to have a Block object that is not directly accessible, without having to go through some proxy-role rigamarole. Something else to consider for these two Use Cases of DTML/Python/Perl Methods/Blocks/Scripts, is that typically only the Block Use-Case is expected to be re-used through recomposition, as well as acquisition, while Templates/Views are usually re-used through Acquisition only. I'm not sure this has any impact on the 'Method Binding' argument floating around, but I thought I'd mention it again in that context. HTH, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope] The Great Python (and Perl) Method Renaming Poll
Michel Pelletier wrote: We will be conducting a community poll to decide what to call Python (Perl, insert your language here) Methods. [snip] So, before the poll, we are calling for nominiations from the community. Please send me an email containing one or more candidate names. These names will be added to the list. No pre-screening will be done, so please exercise some discretion if your favorite name is more tounge-in-cheek than practical (you never know what the masses will decide though!). Later this week, I will create a web poll where you can vote for your favorite. I would like to suggest that instead of a plurality vote, we use a 'Borda count', also known as an 'preferential' or 'single-transferable' ballot. Those of you who followed the recent ICANN election should be familiar with it. It works like this: All votes consist of ranking the availble choices according to desireability (if there are six choices, you would number them 1-6, each choice must be uniquely ranked, not all choices must be ranked). All voters first choices are tallied. If, at this point, one choice has achieved over 50% of the vote, the vote is over. If no choice has achieved 50%, the choice with the fewest votes is removed, and the voters who voted for that choice have their second choice counted and distributed. If at this point one of the choices acheives 50%...etc. Lather, Rinse, Repeat. This method has the advantage of better representing peoples true choice, since no one is tempted to vote for a choice that they simply disapprove of less, because 'otherwise they're throwing away their vote'. In a five-way race for example, a plurality may consist of 25% of the vote, thereby ensuring that 75% of the voters will be pissed off. With a Borda count though, the winner could be everyone's second-favorite choice, thus better representing what people want. There's a few other wrinkles to this, such as situatuions where not all choices have been ranked. If a voter has only ranked four choices and a fifth runoff phase is neccessary, their ballot is discarded, and the 50% mark is recalculated for that phase to account for the reduced number of ballots. Cheers, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Discussion Story Building Mediums
Chris Withers wrote: Michael Bernstein wrote: After some more thought, I realized that this really needs to be a three-way gateway betrween a mailing list, a 'blog, and a newsgroup. I'm all up for doing the mailing list/weblog type bits but I have no idea how news _works_ and how it could be integrated into the Zope environment... Not really, but two-way gateways between mailing lists and News servers are pretty well understood, so it should be possible to let the mailing list sit between the two, and act as a compatibility layer. What do you think? Michael. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ANN: Extended ManagementTabs Mixin for Python Product Developers
Johan Carlsson wrote: Hi, I just uploaded my Extended ManagementTabs Mixin Product you can find it at: http://www.zope.org/Members/johanc/ExtendedManagmentTabs/ExtendedManagmentTabsMixin/ http://www.zope.org/Members/johanc/ExtendedManagmentTabs/ExtendedManagmentTabsMixin/ It's should supply any Python Product with multi-level management tabs without breaking existing code (peppar peppar). If not please let me know. Sounds interesting. Can you add a few screenshots to the product page? Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Validation
Chris Withers wrote: Brad Clements wrote: I keep making this patch to each Zope release, but would like to talk about a more permanant and "correct" solution. What do others think? Validation as a whole could do with looking at, it's be great if there were hooks to catch validation problems rather than just raising exceptions... Along with the TTW ability to define new variable types to be validated (and their validation methods), such as :email, :12hTime, :24hTime, :URL, :fqURL (fully qualified URL), and others. Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Preliminary test of Membership on CVS
Bill Anderson wrote: On a related note, I am considering changing the python methods to Python Scripts, this way when 2.3 comes out, it drops the number of additional installs required by one, leaving Loginmanager and ZPatterns the only (current) requirements. Python Scripts eem much better to use than Python Methods anyway ;) Any thoughts on that from the community? Bill, The move to Python Scripts sounds like a good one. BTW, Can you fold in my local roles changes, and create an additional Type of User Source for use with SMB? I'll contribute the code that I've got. Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Loginmanager and local roles
"Morten W. Petersen" wrote: [Morten W. Petersen] | Any suggestions? Found the problem. There needs to be a method called user_names in the acl_users folder, which returns all the user ids: [snip solution] Sorry I didn't see your question earlier. Here was what I posted to the list back in September when I was having the same problem. Of course, it took me a whole week to figure out. http://lists.zope.org/pipermail/zope-dev/2000-September/006953.html http://lists.zope.org/pipermail/zope-dev/2000-September/007030.html The second posting includes instructions for fixing PersistentUserSouce.py, which is part of Membership. Cheers, Michael. P.S. If you can help generalize the solution so it works for multiple user sources, I'd be grateful. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [squishdot] ZCatalog reindex_object
Chris Withers wrote: Michael Bernstein wrote: reindex_object - should be called when an object is edited Hmmm... didn't see this method listed in the interfaces wiki. Where did you find it? I found it in the 'Creating a CatalogAware ZClass' HowTo: http://www.zope.org/Members/AlexR/CatalogAware/ I just inserted a call to catalog_object which did the job but I wonder what the difference between index_object and reindex_object and catalog_object is? Dunno. Sounds like a question for the main Zope list. HTH, Michael Bernstein ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CatalogAware
Chris Withers wrote: Michael Bernstein wrote: Hmm. Aren't postings CatalogAware? If they're not, shouldn't they be? Why? ;-) Squishdot manages the cataloging, re-cataloging and un-cataloging of its own postings. I don't think CatalogAware would make that process any simpler or more reliable... I guess it's just a matter of only reinventing the wheels you have to, and writing less code as a result. Squishdot seems like it would fall into the category covered by the following howtos: http://www.zope.org/Members/tseaver/inherit_ZCatalog http://www.zope.org/Members/AlexR/CatalogAware But I'm probably overlooking something. Cheers, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CatalogAware
Chris Withers wrote: Michael Bernstein wrote: If you are writing your own cataloging and uncataloging code, then I think that it could be. G The cataloguing code in Squishdot amounts to about 4 lines, all of which are calls to standard ZCatalog interface methods as described in: http://www.zope.org/Members/michel/Projects/Interfaces/ZCatalog If you don't believe me, grep squishdot.py for catalog_object and uncatalog_object... Ok, I believe you! Don't get mad just beacause I was asking a question. I guess I didn't understand. In fact, if catalog_object and uncatalog_object are interchangeable with index_object and unindex_object, then I'm sure I don't understand the point of inheriting from CatalogAware at all. Is it reindex_object, which doesn't seem to have an equivalent? I was asking why Posting objects shouldn't inherit from CatalogAware? That wouldn't actually change the number of catalog-related lines of code in Squishdot. It was merely increase the compelxity of the product by adding CatalogAware as another base class for postings. All right. Scratching-my-head-over-this-whole-CatalogAware-thing-ly yrs, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CatalogAware
Chris Withers wrote: Erik Enge wrote: Are you saying that, as a general rule, inheriting from CatalogAware and using index_object, reindex_object and unindex_object does not work? It probably does, but if you're a catalog yourself anyway, as Squishdot is, it just more overhead rather than calling your own catalog_object and uncatalog_object methods ;-) Aha! You're saying that catalog_object and uncatalog_object are methods of the catalog, so when the catalog contains the objects directly, it's all that's neccessary, correct? index_object, unindex_object, and reindex_object (the CatalogAware methods) are all methods on the object to be indexed, not methods of the catalog, as I understand. When called, they find the nearest (acquisition-wise) ZCatalog (named Catalog by default), and cause catalog_object and uncatalog_object to be called on it (I'm not sure what method reindex_object causes to be called). So, postings would only need to be CatalogAware if you wanted them to be able to 'live' anywhere within the Zope heirarchy, instead of being contained directly within the Squishdot object (which inherits from ZCatalog). Do I have this correct? Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CatalogAware
Erik Enge wrote: [Michael Bernstein] | When called, they find the nearest (acquisition-wise) ZCatalog | (named Catalog by default), I think you can specify the ZCatalog it should index itself in by putting the default_catalog attribute in your class. Your example is correct as far as it goes, but as I understand it, you are not really specifying the default catalog per se, but the default catalog *name*. Therefore, it will then look for the nearest catalog of the name that you have redefined as the default. So if you redefine it to be ZCatalog1, and you have the following structure: / |-/Catalog | |-/ZCatalog1 | |-/folder1 | | | |-/folder1/ZCatalog1 | |-/folder2 Assuming a CatalogAware ZClass has had it's default_catalog defined to be 'ZCatalog1', and that an instance of this ZClass is then added in /folder2, it will index itself in /ZCatalog1, whereas an instance that is added in /folder1 will index itself in /folder1/ZCatalog1. This is my current understanding, I apologise if what I've said is incorrect. HTH, Michael Beernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CatalogAware
Chris Withers wrote:
Michael Bernstein wrote:
Now I'm wondering how to duplicate the behaviour of Postings
being contained within Squishdot, but not appearing in the
'Contents' tab.
that's definitely a 'bad' thing :-(
Why is that bad? A custom object management UI ('Postings'
and 'Moderation' tabs) seems appropriate for Squishdot. I
wouldn't want to manage postings from the standard
management interface.
Why duplicate anyway? You writing a replacement? ;-)
No, I'm creating two different applications, an image
archive and a book catalog. Both need to handle large
numbers of items. The standard management interface does not
scale to the number of objects involved from a usability
perspective.
Neither of my projects need objects to nest (as squishdot
postings do) so I don't need to duplicate the tree
interface, but instead I'll probably create a batching
interface to allow relatively easy access to all contained
objects.
I'd like to know how to prevent the objects being listed in
the 'Contents' tab, while still allowing other objects (like
DTML methods) to be added there.
Any clues?
Michael Bernstein.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CatalogAware
Chris Withers wrote: Michael Bernstein wrote: No, I'm creating two different applications, an image archive and a book catalog. Both need to handle large numbers of items. The standard management interface does not scale to the number of objects involved from a usability perspective. Look at Shane Hathaway's BTree Folder :-) Interesting idea, I hadn't considered that as a solution. Has anyone created a ZClass that inherits from BTree Folder and ZCatalog? I'd like to know how to prevent the objects being listed in the 'Contents' tab, while still allowing other objects (like DTML methods) to be added there. Well, all the postings are actually stored in SquishSite.data, so they're not actually 'contained' in the SquishSite object, hence they don't show up in the contents tab. A bit of magic in SquishSite.__getitem__ makes the postings URL traversable. Interesting. Thanks for the info. I've been using Squishdot a long time, and I never knew that. Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] New UI for 2.3
Steve Alexander wrote: I think the new UI for 2.3 is great improvement over 2.2. I'm already finding the sorted tables of folder contents useful, and having the add new items select at the top saves time. However, I do not like the 3-frame interface. I feel that the top frame is wasted space. The Zope logo and "Logged in as username | Logout" could as easily go at the bottom of the tree-view frame on the left. This would leave extra screen space for doing work. I also much prefer blue to black as a background colour for the tabs and the "Root Folder" link. The black seems a bit overbearing. Hmm. I haven't checked out the new interface myself yet, but I wonder if DC did any usability testing on their new UI? Cheers, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] New UI for 2.3
Brian Lloyd wrote: make a 32 pixel-high concession to a small pittance of branding? The top frame is also a place where we might want to put more "placeless" operations like logout in the future. You can only jam so much into the tree pane without it looking very much like way too much is being jammed into the tree pane :) I think that the top pane contents should be put into the top of the tree pane. In either case, you are pushing the tree pane contents down 32 px, but by putting the logo et al in the tree frame, you will at least not be sacrificing the top 32 px of the main frame. As far as the 'branding' issue is concerned, I do not begrudge DC and Zope the recognition they deserve, as long as it doesn't get in the users way. As an alternative to placing the 'branding' and 'placeless' content into the tree frame directly, you might consider splitting the tree frame instead. This would keep the logo visible, but would no longer take up screen real estate from the main frame. Does DC do any usability testing on proposed UI changes? HTH, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Debugging Zope with Komodo
Andy McKay wrote: My lips are sealed. You're being coy. Here is the URL: http://www.activestate.com/Products/Komodo/ Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns implementation question: images attributes?
RDM wrote: I have a specialist (actually, EMarket has a specialist grin) that manages objects that from a design point of view I think should have a couple of Images as attributes (thumbnail and fullsized images of the product). The question is, how do I implement this using ZPatterns? Currently all of the other object data is pulled from an SQL database. I don't mind storing the Images in the ZODB, but I'm having a hard time finguring out how I would implement that. I've been thinking about my own need for a massive searchable image archive, and have been wondering if I could reimplement the ZPhotoAlbum TTW product (which inherits from ZCatalog and ObjectManager) as a Specialist with a Rack of Photo objects (Photo is a 'normal' Python Product), but I'm unsure of how to go about this. I've also been considering creating an ImageArchive ZClass that inherits from ZCatalog and BTree folder, so I have infrastructure that is better suited to managing thousands (potentially hundreds of thousands) of objects. Any ideas would be welcome. Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Massive scalability
I am currently planning two separate 'Archive' type projects/Products. In both cases, I need to make sure that my implementation will scale to hundreds of thousands or even millions of objects. In one project the objects are very simple ZClasses with a few attributes, in the other project, the objects will be instances of the Photo Product, and considerably larger. One implementation I'm considering is a simple Specialist with a Rack. Does anyone know if there are any inherent limitations on the number of objects that can be stored in a Rack? are there any performance limitations at the scale that I'm talking about? The other implementation I'm considering is to create a ZClass that inherits from ZCatalog and Btree Folder. Would this approach run into any scalability problems with the number and type of objects I'm talking about? Thanks, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Massive scalability
Steve Alexander wrote: Michael Bernstein wrote: I am currently planning two separate 'Archive' type projects/Products. In both cases, I need to make sure that my implementation will scale to hundreds of thousands or even millions of objects. In one project the objects are very simple ZClasses with a few attributes, in the other project, the objects will be instances of the Photo Product, and considerably larger. Do you mean "instances of the Photo Product" or "instances of class FooBar from the Photo Product" ? Sorry. I meant instances of class Photo from the Photo Product. Does anyone know if there are any inherent limitations on the number of objects that can be stored in a Rack? are there any performance limitations at the scale that I'm talking about? If you're talking about the BTree implementation that Racks use when they store data in the ZODB, well, I've never stored more than a few thousand objects in one of those. There certainly aren't the same limitations that you get with the default ObjectManager, as that uses a python dict to hold its sub-objects. The performance limitations will more likely be to do with searching and indexing the data, adding the data in bulk (if you need to do this), and retrieving the data if you have a vast number of clients wanting it all at once. Yes, I was referring to the way a Rack stores data in the ZODB. Photo instances store several sizes of the same image as attributes of the object, as well as various meta-data fields. I anticipate indexing the meta-data in a ZCatalog. Data will not be added in bulk, but several people may want to retreive the data at the same time (if the site becomes popular). The other implementation I'm considering is to create a ZClass that inherits from ZCatalog and Btree Folder. I can't think why you'd want to do that. What role would instances of this class play in your application? The same as the Rack. A single archive of indexed objects. It seems that this would scale better than creating a ZClass that inherits from ZCatalog and ObjectManager as described here: http://www.zope.org/Members/tseaver/inherit_ZCatalog Would this approach run into any scalability problems with the number and type of objects I'm talking about? I think other aspects of your application will determine whether it will scale. Scalabillity is an emergent property of a system. You only get to know about it when you consider the system holisticly. The system is fairly simple: I want to store a large number of objects in a single location, I want to index them in a ZCatalog, I want to find objects by either searching for them, or by browsing a ZTopics based heirarchy (that is populated with ZCatalog searches as well). The search time (whether a user or ZTopic initiates it) should happen fairly fast, regardless of the number of objects (potentially hundreds of thousands), and direct object retreivals (or rendering) should also happen quickly, without major penalties for the number of objects. With Zope, where you store objects and how you plan to find objects, is more significant than what the objects you're storing are. I hope I've explained myself better this time. Thanks for the help, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Massive scalability
Andy McKay wrote: I am currently planning two separate 'Archive' type projects/Products. In both cases, I need to make sure that my implementation will scale to hundreds of thousands or even millions of objects. I would recommend using an RDMBS behind Zope then. Its faster, simpler and I have always had better results. While that would work for the simple object case, I find the prospect of storing a bunch of BLOBs (for the image data of the Photos) in an RDBMS to be *most* un-appetizing. Storing them on the server's file-system seems in-elegant as well. I'd like to build both of these applications as products that can be easily installed into a Zope server (as easily as Squishdot). Adding a dependency on an RDBMS or requiring additional setup on the server's FS seems a step in the wrong direction. I'm working with objects here. I prefer to work with them compared to the approach of decomposing my objects into RDBMS records or files, and recomposing. So the question remains: Will either approach (within the ZODB) allow me to scale the application to hundreds of thousands (or even millions) of objects indexed in a ZCatalog? I should stress that I am far more concerned about the number of objects than I am about the number of 'hits'. I know that the ZCatalog/ObjectManager approach used by Squishdot will scale to over 9,000 objects (the number of postings to date at technocrat.net), So I'm reasonably certain that my proposed ZCatalog/BTree Folder approach will be at least as scalable. I'm slightly less confident about the Specialist/Rack approach, because I don't know of any sites that have used them to store that many objects in the ZODB, but only slightly. However, so far I have not heard of anyone storing and indexing as many homogenous objects as I am talking about. I'd really like to hear from anyone who has attempted to do this or something similar. Does anyone know of any hidden 'gotchas' when dealing with this many objects, regardless of the hit-load on the system? Thanks, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Massive scalability
Jimmie Houchin wrote: I would like to echo Michael's sentiment and comments. I am at the beginning stage of Zope development of a website which will have millions of objects of a single object type and multiple of such. are your objects intended to be indexed by ZCatalog as well, or are you planning some other method of finding your objects? [snip stuff about mounted databases] I think there are many who would like to keep their development within Zope using objects. Any information on best use or development strategies for such setups would be greatly appreciated. Thanks for adding your voice! I also think that applications such as we're discussing should be possible to deploy using nothing but Zope's built in capabilities. I understand that Zope has certain limitations in situations that require many writes to the database, and I accept those limiattions as being a neccessary trade-off for a storage strategy that uses an appending file format. I am still trying to determine if Zope (especially using the two development options I outlined) has any built in limitations regarding the number (or number x size) of objects stored. I really appreciate Zope's features (especially with ZPatterns) that allow applications to be developed that are storage-agnostic, and I feel that this is especially useful for tying into existing legacy systems, but I don't want to develop a new application, storing new data, that is tied to a specific storage methodology such as an RDBMS. People who wish to customize an application to leverage their existing legacy data should be free to do so, but I've noticed that Zope products that have some external system as a pre-requisite (Worldpilot, ZCommerce, etc.) are deployed far less often than those which do not (Squishdot, Zwiki, etc.). So, again: Has anyone run up against any performance or other limitations regarding large numbers (hundreds of thousands or more) of objects stored within the ZODB either in a BTree Folder or a Rack? In other words, will the system slow down if you add enough objects? Thanks, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Massive scalability
John Eikenberry wrote: Michael Bernstein wrote: So, again: Has anyone run up against any performance or other limitations regarding large numbers (hundreds of thousands or more) of objects stored within the ZODB either in a BTree Folder or a Rack? I was looking into the same issues recently, but for a much smaller set of data (5ish). In my tests ZPatterns/binary-trees scaled well for storage and retrieval. But ZCatalog did not. It was basically useless for partial matching searches (taking many minutes for searches that retrieved more than 100 matches) Was this true even for cases where the batch size was smaller than 100? For example, if a search returns over 100 results but the batch size is only 20 (so that only 20 results at a time are displayed), do you still get the performance hit? [snip] I ended up deciding to go with a RDBMS backend for data storage with a ZPatterns interface. SkinScripts work so well for this that I'm actually glad I switched. It simplified my design and implementation immensely. So you're saying that you are doing all searching using SQL statements, and not just object retreival and storage, correct? How are you handling full text searches? Cheers, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Massive scalability
Andy McKay wrote: While that would work for the simple object case, I find the prospect of storing a bunch of BLOBs (for the image data of the Photos) in an RDBMS to be *most* un-appetizing. Storing them on the server's file-system seems in-elegant as well. Okey dokey, just a suggestion. I have heard people talk about large ZOBD's but once I go over a 10,000 object mark I just find a RDBMS easier myself. Go for it good luck! Thanks! I appreciate different points of view on this problem, even if you have different 'comfort zones'. Does anyone know of any hidden 'gotchas' when dealing with this many objects, regardless of the hit-load on the system? Mostly starting and stopping Zope, [snip] Are you saying that Zope's startup and shutdown time is affected by the size of the ZODB? Thanks, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Massive scalability
RDM wrote: On Mon, 15 Jan 2001, Michael Bernstein wrote: as Squishdot). Adding a dependency on an RDBMS or requiring additional setup on the server's FS seems a step in the wrong direction. [...] So the question remains: Will either approach (within the ZODB) allow me to scale the application to hundreds of thousands (or even millions) of objects indexed in a ZCatalog? [...] I know that the ZCatalog/ObjectManager approach used by Squishdot will scale to over 9,000 objects (the number of postings to date at technocrat.net), So I'm reasonably certain that my proposed ZCatalog/BTree Folder approach will be at least as scalable. I'm slightly less confident about the Specialist/Rack approach, because I don't know of any sites that have used them to store that many objects in the ZODB, but only slightly. My understanding is that the point of ZPatterns is to hide the data storage implementation from the application.[snip] The point being that you can *change your mind* later, with minimal disruption to your application. Not only that, but people who *use* your product can make their own decision about where to store the data. So by using ZPatterns you [...] let the users of your product use an RDBMs if that works better for them. Very good points, and ones that I will keep in mind. Thanks. In addition, it seems to me that your comments about ZCatalog+BTree apply equally well to ZPatterns, since you can use the Catalog to index stuff stored in a rack through the use of appropriate triggers, and it is my understanding that the default in-ZODB rack storage uses BTree internally. I do not know if BTree folders and Racks share the same B-Tree implementation, which is why I qualified my statement as 'slightly less confident'. Unfortunately I don't have much input on your question about real-life scalability...the most I've done is stored 6 small objects in a hierarchy of zope folders, indexed by the catalog, with no perceptable slowdown in search or retrieval speed. Hmm. John Eikenberry mentioned a slowdown with about 50,000 objects on partial-match searches, but I don't know how simple/complex the objects were, or how many atributes were being indexed. How many indexes of various types was your ZCatalog maintaining on your objects? Thanks, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCatalog with ZClass
Lily Li wrote: Hello, everyone, It seems that many of you have used ZCatalog pretty well. My problem is that I'd like a ZClass (of a Product) to subclass CatalogAware, and implement all the index and search inside the Product. That means I don't want to do any DTML method stuff outside of the Product. What you probably want is to create a repository that subclasses ZCatalog as is described in this HowTo: http://www.zope.org/Members/tseaver/inherit_ZCatalog And then add your CatalogAware ZClasses into it. Then you can set up your ZCatalog/ObjectManager with search methods. HTH, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] [Fwd: Re: [Zope-dev] Massive scalability]
Forwarded to the list to maintain the thread. Original Message From: John Eikenberry [EMAIL PROTECTED] Subject: Re: [Zope-dev] Massive scalability To: Michael Bernstein [EMAIL PROTECTED] Michael Bernstein wrote: John Eikenberry wrote: Can you tell us a bit about how many indexes (and what types) you were maintaining about each object? Another poster reported no problems with 60,000 objects. I was testing and had a real simple setup. In addition to the default indexes I had 1 index on a string type (of 10 chars or less - last names), 2000 objects indexed. The vocabulary only had the entries for this field in it. Everything was nice and fast except partial searching. It was fast enough when ther were small numbers of matches. But as the number of matches grew the time it took grew along with it, at a nearly expontial rate. -- John Eikenberry [[EMAIL PROTECTED] - http://zhar.net] __ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: ZCatalog Scalability
Christopher Petrilli wrote: Unfortunately, it won't change in b1, it might change before the final release if I can find a better solution. The problem is in the Vocabulary, not in the Catalog itself. One of the things I'm focusing on is improving the algorithms that are used for doing globbing. Which problem is the algorithm improvement meant to address, bulk adds or partial search performance? Thanks, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Specialist/Rack scalability
After comsidering the fedback I got from the previous 'Massive scalability thread, I decided to split my queries into two areas: Rack scalability and ZCatalog scalability. This email deals with the former. It seems clear that indexing and searching are more of a botleneck than storage/retreival. Nevertheless, so far I have not heard of anyone trying to store more than 60,000 objects in a rack. I need to know if there is any reason to suspect that storage (in the ZODB) or retreival performance would suffer if the number of objects was in the hundreds of thousands or even millions. Does anyone have anectodal or benchmark data that would suggest what happens with that many objects? Thanks, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ZCatalog scalability
After comsidering the feedback I got from the previous 'Massive scalability' thread, I decided to split my queries into two areas: Rack scalability and ZCatalog scalability. This email deals with the latter. Partial match (wildcard) searches have already been identified as a resource hog, depending on the size of the result list. I am more than willing to give up wildcards in my application for performance. What I am interested in for my application are two things: - ZTopics populated using one or more keyword indexes - Full text search on a single computed attribute that concatenates several fields including the aforementioned keyword index fields and a few simple string attributes (title, caption, description, etc.) I need to know how far the ZCatalog will scale using this indexing and search strategy. Does anyone have anectodal or benchmark data to suggest if (and when) I will hit a 'wall' regarding the number of objects being indexed and searched? Some anectodal data suggests that single field indexing will scale easily to 60,000 objects, what about hundreds of thousands or even millions of objects? Also, is there a way to disable wildcards in full text searches? Thanks, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCatalog scalability
Steve Alexander wrote: Michael Bernstein wrote: Also, is there a way to disable wildcards in full text searches? Do not allow direct queries to search the catalog. Instead, make searches go through an external method (or a PythonScript with Proxy permissions) that uses string.replace to change '*' and '?' to ''. A *very* handy suggestion. You might want to add that as a Tip to Zope.org. Thanks, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCatalog scalability
Erik Enge wrote: [Michael Bernstein] | I need to know how far the ZCatalog will scale using this indexing | and search strategy. Does anyone have anectodal or benchmark data to | suggest if (and when) I will hit a 'wall' regarding the number of | objects being indexed and searched? I'm going to try to stuff 27 million objects into ZODB sometime in the next week or the week after that (all post addresses in England). I haven't got a clue as to whether this will work or just... well not work. I haven't come up with a strategy for segmenting the data, but that shouldn't be a problem at all. This isn't actually much data, so I don't expect the Data.fs file to more than 500 MB. I'm quite confident that ZODB, ZCatalog and BTree will scale very nicely for this. I have a plan ;). I'll let you know how it goes. (And please, do poke at me if it takes too long. Will do, Thanks! Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Specialist/Rack scalability
Steve Alexander wrote: Hi Michael, Michael Bernstein wrote: It seems clear that indexing and searching are more of a botleneck than storage/retreival. Nevertheless, so far I have not heard of anyone trying to store more than 60,000 objects in a rack. I need to know if there is any reason to suspect that storage (in the ZODB) or retreival performance would suffer if the number of objects was in the hundreds of thousands or even millions. [snip] So, storing things in a Rack happens in a number of stages: Your application interacts with the Rack The Rack (perhaps) stores the object persistently in its BTree The BTree is a collection of persistent ZODB objects The ZODB objects are stored as Python Pickles in a FileStorage We can consider what the effect of storing 60 000 objects is at each of these interfaces. Are there any differences if you scale the number of objects up to the hundreds of thousands or even into the millions? The Rack shouldn't have a problem with 60 000 objects. I doubt a BTree would have a problem. The ZODB might not like accessing many large objects during a single transaction, as all those objects need to be in memory at once. Neither of my applications require batch adds to the DB, however, one of them (the image archive) has objects (Photos) with several images as attributes. This results in a fairly large object. There is some question in my mind if accessing any attribute (such as the thumbnail version) causes all attributes to be loaded into memory. If so, displaying a list of images with thumbnails may result in many large objects being loaded into memory. A FileStorage should have no problem reading 60 000 stored objects. However, if these objects are changing much, your Data.fs will grow fast. In any case, you may find undo and history screens take a long time to appear. No. Once added, I don't expect the data to change frequently. Thanks for the feedback. Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Specialist/Rack scalability
Steve Alexander wrote: Michael Bernstein wrote: There is some question in my mind if accessing any attribute (such as the thumbnail version) causes all attributes to be loaded into memory. If so, displaying a list of images with thumbnails may result in many large objects being loaded into memory. Make sure that each large attribute is an instance of a class that derives from Persistent. Ok, I'll give that a try. Since Photo is a Python Product, what will happen to current instances if I make this (and only this) change? Of course, if this is a ZPatterns application, you'd probably want to have the images in their own Rack, and use an Attribute Provider on your Photo objects that gets the images for a Photo as needed. The Photo (with meta-data) and the images are entirely different objects, accessed via different Racks, via different Specialists. I'm not certain that that makes sense, since the Images are really cached 'views' of the Photo object. When a new image is uploded to replace an existing one, *all* versions (thumbnails, small, medium, large, etc) are regenerated. But assuming that I went so far as to break out the Images to their own Rack, would you reccomend that each image size have a dedicated Rack, or would you suggest that all images be stored in the same Rack? Thanks, Michael. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Specialist/Rack scalability
"Phillip J. Eby" wrote: Just to expand a little on the abov... Racks should scale at least as well, if not larger than a ZCatalog, given the same storage backing for the ZODB. This is because ZCatalog has to manage a minimum of one forward and reverse BTree for *each* index, plus another few BTrees for overall storage and housekeeping. Also, keyword and full text indexes store multiple BTree entries per object, so that's a factor as well. So don't worry about the Rack. If you're using a Rack, you can store the data anywhere, and you can index it in an RDBMS, LDAP directory, ZCatalog, or some combination thereof, using triggers to keep the data in sync. Thanks Philip, that's reassuring. I guess now I need to make certain that the ZCatalog can scale as far as I need it to. Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCatalog scalability
We seem to have disposed of the wildcard issue [snipped out below], and I'm looking forward to Eric's results, but does anyone else have any information about whether there is a practical upper limit on how many objects can be indexed and searched in a ZCatalog? Michael Bernstein wrote: After comsidering the feedback I got from the previous 'Massive scalability' thread, I decided to split my queries into two areas: Rack scalability and ZCatalog scalability. This email deals with the latter. [snip] What I am interested in for my application are two things: - ZTopics populated using one or more keyword indexes - Full text search on a single computed attribute that concatenates several fields including the aforementioned keyword index fields and a few simple string attributes (title, caption, description, etc.) I need to know how far the ZCatalog will scale using this indexing and search strategy. Does anyone have anectodal or benchmark data to suggest if (and when) I will hit a 'wall' regarding the number of objects being indexed and searched? Some anectodal data suggests that single field indexing will scale easily to 60,000 objects, but what about hundreds of thousands or even millions of objects? [snip] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCatalog scalability
Erik Enge wrote: [Chris Withers] | ...and is that specifically for BTree folders, or Zope BTree's in general? I don't believe that B-Tree folders have those kinds of limitations by general design. I'm more conserned that somewhere along the lines, doing operations on a huge BTree Folder (Yes, in Zope) will be slow. What sort of 'operations' do you mean? copying and pasting the whole thing? Hm, more over, if you actually need to stuff that many objects into one Folder, you are probably trying to use the wrong tool for the job. I do expect that stuffing 27 million objects into one BTree Folder will be slow, and I don't want to segment the data. I do expect that I'll have to resort to a relational database, and I have no problem with that. Object databases aren't always the right tool for the job, and when they aren't, Zope let's me talk with the other ones nicely, so no problemo seor ;). Eric, I had separated the storage issue into a different thread (Specialist/Rack Scalability), and received a reply from Phillip Eby: Just to expand a little on the abov... Racks should scale at least as well, if not larger than a ZCatalog, given the same storage backing for the ZODB. This is because ZCatalog has to manage a minimum of one forward and reverse BTree for *each* index, plus another few BTrees for overall storage and housekeeping. Also, keyword and full text indexes store multiple BTree entries per object, so that's a factor as well. So the question I was asking is: "if we ignore the issue of storage and consider indexing and searching the ZCatalog alone, and assuming that wildcard searches are disallowed, how far will a single ZCatalog with a text index (on a computed attribute that concatenates several properties) and a keyword index (for creating ZTopic heirarchies) scale?" While I'm perfectly willing to split up the storage of the data as neccessary, I am far less enamoured by the prospect of divvying up the indexing and searching to multiple ZCatalogs. In any case, according to Phillip, if I don't have to split the ZCatalog, I shouldn't have to split the storage (in Racks, anyway, but probably BTree Folders too), either. Anyway Eric, I hope that when you report your results, you're able to separate indexing, searching, storage, and retreival results, so that the appropriate factor can be identified as the bottleneck. Or at least into indexing/searching and storage/retreival. Thanks, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Mapping multiple IP addresses/domains to one Zope
Aaron Gillette wrote: My company has many sites which share some content. Each site uses a different IP address. I would like to bring all of these sites into one instance of Zope on an NT machine. I am looking at the possibility of either 1) running Zope behind IIS, or 2) running Zserver exclusively. You have a third possibility, which is to run Zope behid Apache on NT. I would guess that this list has more experience with Apache rewrite rules than IIS. This setup should also be fairly easy to migrate to Linux. Personally, I've found it more convenient to point all my domains to a single IP address, and let Zope (with help from SiteAccess) handle the rest. This has been easier, even though Zope is behind Apache, as Zope Access Rules are easier to create (IMO) than dealing with name or IP based virtual hosting under Apache. Those Apache rewrite rules are horribly cryptic. HTH, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] test, please ignore
test ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Q: Specialists, Racks, and ZCatalogs?
Hi all, I've started implementation of a simple ZPatterns based application, and so far things have been going well. The problem is, I'm not sure if I'm doing this right. Here is my setup: Zope 2.2.0 hosted at Codeit.com on a Linux box ZPatterns 0.4.3b2 'BookProduct' product *'BookClass' ZClass (inherits from _ZClass_for_CatalogAware, _ZClass_for_DataSkin) * Methods: editInstanceForm, editInstance, index_html, AllTextMethod 'Books' Specialist * defaultRack which stores 'Book' ZClasses * Methods: addBookForm, addBook, index_html, BookSearch, BookResults (the last two methods are a Z Search Interface) *'Catalog' ZCatalog The 'BookClass' editInstance method contains: [snip] dtml-call "propertysheets.Standard.manage_changeProperties(REQUEST)" dtml-call reindex_object [snip] The 'Books' Specialist's addBook method contains: [snip] dtml-let ni="newItem(isbn)" dtml-call "ni.propertysheets.Standard.manage_changeProperties(Authors=Authors, Title=Title, Price=Price)" dtml-call "ni.index_object()" /dtml-let [snip] I've snipped out only the most relevant parts of these methods. As I said, so far this has worked ok. But it seems to me that either the reindex_object or the index_object is in the wrong place, but I'm not sure which. I'm also not sure it's a good or bad idea to place the ZCatalog directly into the Specialist. Also, I would like to replace the three indexes I'm maintaining on the books with a single text index on a computed attribute. I understand that this involves adding a SkinScript to the Rack containing something like 'WITH SELF COMPUTE AllText=AllTextMethod', but I'm unsure of the details. I have a method (AllTextMethod) on the ZClass that returns several fields concatenated as a single string, which I would like to use as a text index. So, I decided to ask for a critique of the application design (such as it is). I also seem to recall mention of 'indexing agents' that might make this a bit more elegant, but haven't found a how-to on the subject. Thanks, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] How to get the mailing list to work
Just address your emails to [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?
Steve Alexander wrote: Michael Bernstein wrote: 'BookProduct' product *'BookClass' ZClass (inherits from _ZClass_for_CatalogAware, _ZClass_for_DataSkin) Don't derive from CatalogAware when you're also deriving from DataSkin. Ok. Rather than use the CatalogAwareness mechanism to manually call reindex() when your object changes, you should use some SkinScript in your Specialist or in your Customizer to catalog, uncatalog and recatalog on changes. WHEN OBJECT ADDED CALL Catalog.catalog_object(self, _.string.join(self.getPhysicalPath(),'/')) WHEN OBJECT DELETED CALL Catalog.uncatalog_object(_.string.join(self.getPhysicalPath(),'/')) WHEN OBJECT CHANGED CALL Catalog.uncatalog_object(_.string.join(self.getPhysicalPath(),'/')), Catalog.catalog_object(self, _.string.join(self.getPhysicalPath(),'/')) Thanks, Steve. I'll try this a little later today. What are your thoughts on placing this in the Specialist's 'Plug-ins' tab vs. the Rack's? [snip] Also, I would like to replace the three indexes I'm maintaining on the books with a single text index on a computed attribute. I understand that this involves adding a SkinScript to the Rack containing something like 'WITH SELF COMPUTE AllText=AllTextMethod', but I'm unsure of the details. I have a method (AllTextMethod) on the ZClass that returns several fields concatenated as a single string, which I would like to use as a text index. You don't need a method for this; do it all with SkinScript like this: WITH SELF COMPUTE all_text='%s %s %s' % (title, headline, content) Thanks again, Steve. Cheers, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?
Steve Alexander wrote: Michael Bernstein wrote: Thanks, Steve. I'll try this a little later today. What are your thoughts on placing this in the Specialist's 'Plug-ins' tab vs. the Rack's? [snip excellent explanation] Thanks, Steve. That was very helpful. To summarize your explanation, if I understood correctly: This is strictly an implementation issue. If the SkinScript has functionality that should be shared by more than one Rack, it should go in the Specialist, otherwise keep it with the Rack that it's specific to. Or, looked at another way, common functionality should be factored out and acquired. All in all, a very 'Zopish' principle. Cheers, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?
Steve Alexander wrote: Michael Bernstein wrote: If the SkinScript has functionality that should be shared by more than one Rack, it should go in the Specialist, Not quite. If the SkinScript has functionality that is shared by all the Specialist's Racks, then it should go in the Specialist. If the functionality is shared among *most* of the Racks, can't you override the SkinScript in the exceptions? Although you can do that, it is not always the best thing to do. Sometimes, a bit of redundancy helps ease a system through the pains of evolution :-) On that subject, does anyone know why SkinScripts don't support cut-n-paste or copy-n-paste? Thanks, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: BTreeFolder
Shane Hathaway wrote: Chris Withers wrote: will you be releasing a new version of BTreeFolder that makes use of the new funky BTrees at any stage? We've done some work on it; in fact Jim came up with a bold new idea that makes them inherently faster. Now to find the time. :-) Does this have any implications for the BTree implementation used in ZPatterns Racks? Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CatalogAware
Chris Withers wrote: Michael Bernstein wrote: I guess it's just a matter of only reinventing the wheels you have to, and writing less code as a result. I'm pretty sure Squishdot is re-inventing no wheels ;-) If you are writing your own cataloging and uncataloging code, then I think that it could be. http://www.zope.org/Members/tseaver/inherit_ZCatalog http://www.zope.org/Members/AlexR/CatalogAware These are both pretty old and seem to be aimed at ZClasses. Squishdot has nothing to do with ZClasses. I realize that Squishdot is a Python product, of course. As far as the information being old, it's tested. I just used it to build a new application this week. No bugs. CatalogAwareness is of no use for a product like Squishdot. Squishdot already inherits from ZCatalog. I realize that Squishdot already inherits from ZCatalog, I was asking why Posting objects shouldn't inherit from CatalogAware? I don't think that only ZClasses can inherit from CatalogAware, that doesn't seem quite right. Again, it's certainly possible that I'm overlooking something. Cheers, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] dtml-in batching badly
seb bacon wrote: * Joachim Werner [EMAIL PROTECTED] [010618 20:28]: That's not the behaviour I'd expect. Can anyone confirm this is a bug? As LEE Kwan Soo has already said, it is not a bug, but a clever (too clever?) feature that should maybe not be enabled by default. Every second week or so somebody runs into this and thinks it is a bug. Thanks for the hint, folks. I'm not a zope newbie, and this still bit me. IMO there's something fairly wrong with the current setup. either the default behaviour should be changed to orphans=0, or the visibility of default values for tags should be improved (from the book: orphan=int The desired minimum batch size - no mention of defaults). Furthermore, the 'feature' doesn't work as I'd expect. In the example I posted, for the sequence (1,2,3,4), I got: batch 1: 1 batch 2: 2 3 4 batch 3: 3 4 batch 4: 4 This isn't in batches of at least 3... If it were iterating in minimum batches of 3, shouldn't that be: batch 1: 1 2 3 batch 2: 2 3 4 batch 3: 2 3 4 batch 4: 2 3 4 Orphan control shouldn't actually set the desired minimum batch size, it should set the size at or below which the last batch should be combined with the next to last batch. If my batch size is five, and orphan is set to three, and I have a set of eight records that I am iterating through, I will get a single eight record batch, because the orphan setting tries to prevent the last batch having three or less results by combining them with the previous five. Orphan settings typically do not override where the batch starts (that would be a 'widow' setting) only where it ends, which is why you are getting increasingly smaller batches. However, the fact that you are getting four batches (rather than just one) is arguably a bug. A batch size of one, combined with an orphan setting of three, should actually give the following result: batch 1: 1 2 3 4 But the algorithm doesn't seem 'smart' enough to roll-up the batches by recursing through them in reverse order. Arguably though, you should never set your batch size smaller than the orphan size, so this isn't really an issue. Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: Rename zope package
Jim Fulton wrote: Based on recent discussions, I've created a proposal: http://dev.zope.org/Zope3/RenameTheZopePackage to rename the zope package to z. Unless there are strong objections, we'll do this after we move the Zope repository head to subversion at the end of the month. From a consistency in nomenclature POV, I find 'z' jars a bit with ZConfig, zdaemon, ZEO, zLog, and ZODB, which one might expect to find nested within 'z' (as 'z.Config' for example). This is admittedly only an issue for the newest newbies still trying to guess at where stuff is located. However, rather than suggest a wholesale moving and renaming of these packages within 'z', I'd like to suggest an alternative short name for the 'zope' package, 'OPE', which avoids this issue: import OPE.interface from OPE.app import zapi from OPE.app.event import publish from OPE.app.event.objectevent import ObjectModifiedEvent Cheers, -- - Michael R. Bernstein ___ 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 )
Re: [Zope-dev] Proposal: Rename zope package
Fred Drake wrote: On Friday 16 April 2004 01:31 pm, Michael Bernstein wrote: From a consistency in nomenclature POV, I find 'z' jars a bit with ZConfig, zdaemon, ZEO, zLog, and ZODB, which one might expect to find nested within 'z' (as 'z.Config' for example). This is admittedly only an issue for the newest newbies still trying to guess at where stuff is located. I don't know what zLog is; presumably you mean zLOG? Yep. zLOG is dead in Zope 2.8, and will remain only for API compatibility. I don't think there's any real consistency now for what's in the Zope 2 head, so I don't think that's a big deal. Shouldn't we strive for consistency in nomenclature going forward? However, rather than suggest a wholesale moving and renaming of these packages within 'z', I'd like to suggest an alternative short name for the 'zope' package, 'OPE', which avoids this issue: import OPE.interface from OPE.app import zapi from OPE.app.event import publish from OPE.app.event.objectevent import ObjectModifiedEvent Hehe. ;-) (I do hope you're joking!) About even considering a 'wholesale moving and renaming' yes, obviously, but as far as suggesting 'OPE' as an alternative to 'z' (insofar as it is still necessary to avoid a name-clash with 'Zope'), no. 'OPE' (as an acronym for Object Publishing Environment) seems like it fits better conceptually than 'z'. Did I miss something? Did I just manage to embarrass myself? Is this a dream where I find I am wearing nothing but underwear in public and then wake up? -- - Michael R. Bernstein michaelbernstein.com Author of Zope Bible ___ 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 )
Re: [Zope-dev] Proposal: Rename zope package
Shane Hathaway wrote: Michael Bernstein wrote: Did I miss something? Did I just manage to embarrass myself? Is this a dream where I find I am wearing nothing but underwear in public and then wake up? Well, OPE made me think of: - Opie on The Andy Griffith Show - http://www.imdb.com/title/tt0053479/ - Spelling it zOPE to take advantage of a frequent mishap involving the cAPS lOCK key - Shouting the name of the product repeatedly in code as a method of advertising How about 'ope', then? Actually, I don't really care what it's changed to. Jim is right in that it needs to be changed, and I thought 'z' to be not-so-great a choice for the reasons I already gave (in addition to some of the cons that Jim lists in his proposal). An optimal choice probably doesn't exist, though. I thought it was funny. :-) Do I *amuse* you? ;-) -- - Michael R. Bernstein michaelbernstein.com Author of Zope Bible ___ 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 )
Re: [Zope-dev] Re: [Zope3-dev] Zope and zope
Jim Fulton wrote: Jim Fulton wrote: The first question is: Is it a problem to have two packages with names differing only in case? +1 -- - Michael R. Bernstein michaelbernstein.com Author of Zope Bible ___ 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 )
Re: [Zope.Com Geeks] Re: [Zope-dev] zope-dev list policies
Ken Manheimer wrote: I noticed this when it went initially went by, but didn't have time to follow up. The upshot is that there is absolutely no way *under the current arrangement* that this is going to happen. I can see a way to swing it, requiring earnest volunteer effort. Here are the details. Being the administrator of many of the zope lists (probably over ten and below twenty), i am already dismayed by the challenge of the typically thirty to one hundred held spam messages, bounces, and other effluvia i have to handle *per day*. I do not know how many of the legitimate list messages would additionally be held and require more attention (with the current mailman implementation, it takes a lot more fuss to approve a held message than to discard it), but the load is already untenable, so one more is too many. I believe the proposal wasn't to *hold* non-member emails, but to bounce them or discard them, so your workload should actually be reduced. -- - Michael R. Bernstein | Author of Zope Bible michaelbernstein.com | Zope.org Webmaster panhedron.com |PythonPhotos.org ___ 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 )
Re: [Zope-dev] Re: zope-dev list policies
Casey Duncan wrote: -1 on changing the list policy. I read and post to all of the public lists through Gmane, which won't work if the policy is changed. Umm... Why wouldn't this work? Isn't Gmane a subscriber? -- - Michael R. Bernstein | Author of Zope Bible michaelbernstein.com | Zope.org Webmaster panhedron.com |PythonPhotos.org ___ 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 )
