Re: [Zope] Values lost when restarting
On Tue, 2007-01-09 at 17:09 +0100, Andreas Jung wrote: --On 9. Januar 2007 17:06:24 +0100 Jonas Nielsen [EMAIL PROTECTED] wrote: The Zope Bible says something about calling self.__changed__(1) after updating the value but this doesn't seem to work even though the objects inherits from Persistent self._p_changed = 1 Well, I suppose that's the final nail in the coffin for the Zope Bible (like it actually *needed* another one at this point). I think the self.__changed__(1) spelling I used was deprecated even before I wrote the book, and I guess the supporting code must have been taken out of the ZODB since then. So, just shoot me and go pre-order Philipp's book now: http://www.amazon.com/exec/obidos/ASIN/3540338071/fiawol/ref=nosim Cheers all, - Michael R. Bernstein michaelbernstein.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
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 )
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-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] 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] 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] 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 )
[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 )
[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 )
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 )
Re: [Zope] Is it possible to make a thumbnail from an added image..?
3dfestival - WebMaster wrote: Just a quick Idea: Can somebody make a routine RESIZING an image...? It would be great if someone could make something like that... Just imagine it: You add an Image_with_thumb... Browse for the image, then it adds your image to the site AND it is being resized to, for instance, 16x16pixels, and you can use that thumb as an icon for the image...! Wouldn't that be great...? Check out the Photo Product: http://www.zope.org/Members/Drew/Photo HTH, Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
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] 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] Zope 2.3.0b2 bug #2
Oleg Broytmann wrote: On Mon, 22 Jan 2001, Brian Lloyd wrote: FYI - I've taken out the charset declaration altogether for beta 3, Thanks. since this is obviously an issue that needs more thought. Since Sure. Language/encoding issues are hard to implement, though. There are servers, proxies, browsers - and almost none of them obey standards correctly :( The chosen language/encoding solution will likely have to be implemented along with some sort of language/encoding policy interface, so that the exact behaviour can be set by the server administrator, and possibly overridden by managers at different points in the tree. I would suggest that the default setting (in the startup script) be fully standards compliant, but a systems administrator should still be able to select another behaviour for Zope if they wish (including disallowing managers to override). Sorry this is a bit vague, need coffee. Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[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] Mental disconnect help: Zope objects vs. Python objects in ZODB
Max Mller Rasmussen wrote: Whops... The missing link http://www.zope.org/Members/maxm/HowTo/minimal_01/index_html Whoa. I am *seriously* impressed with the clarity you've brought to this subject. Thank You! Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[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 )
Re: [Zope] Zope Versus Enhydra Comparison article
Ron Bickers wrote: Using Zope we knew that we would reach situations which may be unresolvable in the short term, and could not make significant business decisions with so many unknown factors and lack of any way to circumvent problems. What in the world does that mean?!? Maybe it should read "We don't know how to use Zope or code in Python." I can give you a personal example. When I was trying to get LoginManager to display it's stored users in the local roles security form, I couldn't fix it using what I knew, which was DTML and ZClasses. I had asked for help on the lists, and got some pointers in the general direction, but that was all. After a week of crawling around in Zope's source (and a lot of whining), I found the parts I needed to duplicate for PersistentUserSource.py, and I added them. It should not have taken me a week, except that I don't really consider myself a coder. The only thing that made it possible at all was my extensive experience *using* zope, and my familiarity with Tracebacks and a basic understanding of most of Zope's underlying mechanisms. If I had been a real Zope/Python coder, I probably would have figured it out in a day. However, for a programmer who had to come into the Zope environment 'cold', the problem would likely have seemed intractable. They wouldn't have even known where to look, and the fact that LoginManager is not an 'official' core Zope product could have been a show-stopper. (Why did I have to use LoginManager, you ask? Membership requires it, and I needed to store user data in the ZODB about NT authenticated users on a Solaris box. Gah). So the problem, as I see it, is multiple dependencies that may not be obvious. While over the long term, factoring common functionality into separate products that other products depend on makes more sense, and creates a *much* more powerful framework, in the interim (waiting for things to jell) it can frustrating as all get-out, and pretty easy to get stuck. Conversely, that things about Zope that are relatively mature are a dream to use and leverage, so this is an acceptable trade-off for me. Cheers, Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope 2.3.0 beta 1 comments
Martijn Pieters wrote: On Wed, Jan 17, 2001 at 04:00:57PM -0500, Brian Lloyd wrote: - When you view a management screen, the frame is about 5 pixels to small, which cuts off the bottom of the Zope logo. I'm looking into fixing that. This suddenly rings a bell; I remember now that NS4 seems to have a 'grid' system for laying out frames. It snaps to certain sizes, and adding a few pixels plus or minus won't get you a visible change. Sizing of frames can only happen in larger steps. Here's a throrough description of the problem: http://www.builder.com/Authoring/Tagmania/120699/index.html HTH, Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope Versus Enhydra Comparison article
Ron Bickers wrote: However, for a programmer who had to come into the Zope environment 'cold', the problem would likely have seemed intractable. They wouldn't have even known where to look, How does Enhydra differ? Wouldn't the same problems be true for someone working with Enhydra that knows Zope/Python really well but has zero Enhydra/Java experience? Please scan through their 'getting started' document: http://www.lutris.com/documentation/lutris-enhydra/35/books/index.html?getting-started You'll see that Enhydra, like most app-servers, is basically a thin layer on top of a relational data model. What infrastructure is there is basically aimed at easing the pain of bridging the object-relational gap. To that end, they have a lot of Wizards that automate boring tasks, and present the the OR mapping in a pretty graphical interface. Great. They also provide some of the basic low-level building blocks for web applications like session managers. Wonderful. They even cleanly separate the presentation- and business-logic layers for you. Woohoo. User mangement? Build your own. ACL security? Build your own. Etc. Faced with a situation like this, a programmer will typically build *exactly what they need*, and no more. Every site an island. And all of this is built on top of Enhydra's core functionality. Zope's approach, of generalizing and integrating common design patterns into the core product, tends to poke developers in a different way. Consider LoginManager. LM is a product that is designed to be a drop in replacement for Zope's existing acl_users objects, but to be more extensible. Faced with a generalized solution that I could extend to authenticate using SMB and still store user info in the ZODB, but that doesn't correctly participate in Zope's local roles machinery, my initial reaction was to *fix it*. Which I did after a week of whacking on it. Which was itself the culmination of a month of, well, whacking on other aspects of the problem. An Enhydra developer would have developed a custom solution for managing their user objects. It would not have been as generalized, almost certainly would have included only simple permission flags used at the Business Object layer, and had other deficiencies that I won't ennumerate. But it would have done exactly what he needed to do right then. I, on the other hand, after solving the local roles problem, was able to install Membership, tweak the Tracker product to use the getUserNames method, change a few permissions on a Squishdot instance, and pretty soon I had myself a nice little NT authenticated Intranet on the Solaris box, one that I *knew* was extensible. Thus, it was worth the pain of having to delve into Zope's source. In conclusion, Enhydra, like most application servers, hides it's internals behind lowest common denominator interfaces, and encourages you to build on top of them. Zope, on the other hand, tries to create 'highest common denominator' interfaces and frameworks, and encourages you to extend or override them. This results in Enhydra developers needing to know Java plus Enhydra's idioms, wheras Zope developers need to know Python and Zope's *internals*. HTH, Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
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 )
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
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] 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] Newbie question: HTTP variables
Dean Deb Ekstrand wrote: I'm trying to figure out Zope (on a time crunch, too), and I'm wondering how to do something. How can I access HTTP variables in my DTML code? Specifically, I want to return code specific to the user's browser. I know that HTTP has provisions for determing browser version, are those accessible in DTML and how? If they are not accessible in DTML, is there a workaround (without oodles of javascript)? these variables are part of the REQUEST namespace. Specifically you can do dtml-var "REQUEST.HTTP_USER_AGENT" to display the browswer version. Creating conditional code is left as an excersize for the student. If you want to display a complete list of all HTTP REQUEST variables, try this: dtml-var REQUEST Another quick question: I see that Zope 2.3 will have "Script" objects. What's the closest I can come in Zope 2.2.5? The Python Method product: http://www.zope.org/Members/4am/PythonMethod Or external methods: http://www.zope.org/Documentation/How-To/ExternalMethods HTH, Michael Bernstein ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Collector Product ??
Peter Bengtsson wrote: I'm looking for a bug-tracking-software-system. Does DC give out their Collector (http://classic.zope.org:8080/Collector) Product for free for us? Where can it be downloaded? Is there anybody out there who would care to share their product with me? ;) The collector has been superseded by the Tracker. It's an unsupported product, but you can get it through CVS: http://www.zope.org//Members/klm/TrackerWiki/FrontPage Here's another one, a bit less sophisticated, but easier to set up and use: http://www.zope.org/Members/shalabh/iTrack HTH, Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
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] 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] 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] 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: 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: 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: 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] First Project
Koch Marc wrote: Please let me ask your advice on how to realize the following: I would like to build an application for handling development requests. These requests should be submitted by our end-users through our Intranet to my team. We then look at each new request and dispatch it to one or more development team for approval (or rejection). At this stage: - The end-user should be able to see that his request has been dispatched - The concerned development team(s) should see that there is a new request, they could look at it and accept it or reject it and give a comment When all the teams have replied, my team would add a summarized comment to the request and the end-user should be able to see this. At this point, the request handling for my team is at its end. Requests should be submitted by a Web-Form and may contain an arbitrary file (eg. Word Document). The end-user and the development team should see only what they are concerned with. My team needs a global overview. Check out the Tracker product: http://www.zope.org/Members/klm/TrackerWiki/FrontPage HTH, Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
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 )
[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] tuples in DTML
Max M wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael
Bernstein
dtml-in "External_Method(REQUEST)"
dtml-var sequence-itembr
/dtml-in
Which (of course) displays the list as an single item along
with each of the strings:
['list item 1', 'list item 2', 'list item 3']
String 1
String 2
String 3
Now, how do I iterate over the list in DTML?
dtml-call REQUEST.set('the_list', External_Method(REQUEST)[0])
dtml-in the_list
blah blah dtml-var sequence-item
dtml-in
Something like the above ought to work.
Mmm, It doesn't seem quite right. If I do it that way, I'll
have to run the external method more than once, and it's a
relatively expensive method. I'm opening an HTTP connection
and processing the page to extract the data that is getting
put into the tuple.
What if I do:
dtml-call "REQUEST.set('the_tuple',
External_Method(REQUEST))"
dtml-call "REQUEST.set('the_list', the_tuple[0])"
dtml-in the_list
bdtml-var sequence-item/bbr
/dtml-in
dtml-var "the_tuple[1]"br
dtml-var "the_tuple[2]"br
dtml-var "the_tuple[3]"br
Ok, this works!
Thanks for the help,
Michael Bernstein.
___
Zope maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope-dev )
[Zope] tuples in DTML
Hi everybody, I've been messing with some external methods and I've got one that returns a tuple. The tuple consists of a list and a few strings. How do I access the tuple elements from DTML? Cheers, Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] tuples in DTML
Michael Bernstein wrote: Hi everybody, I've been messing with some external methods and I've got one that returns a tuple. The tuple consists of a list and a few strings. How do I access the tuple elements from DTML? Ok, I've been messing with it some more and I should have tried simply iterating over the tuple elements before: dtml-in "External_Method(REQUEST)" dtml-var sequence-itembr /dtml-in Which (of course) displays the list as an single item along with each of the strings: ['list item 1', 'list item 2', 'list item 3'] String 1 String 2 String 3 Now, how do I iterate over the list in DTML? Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Editing the z2.py File
Stephane Bortzmeyer wrote: - do not make *one* mistake in the "root" method code or you will lose access to your Zope completely (that's the big problem with all-database systems like Zope). Even FTP access will fail, you will have to retrieve your ZODB from backups! Umm, even if *everything* else fails, you can still manually truncate the Data.fs file to remove the last transaction (presumably the change you made to the access rule), and you'll be back to normal. That's one of the things that I really appreciate about Zope, that it's practically (though not absolutely) immune to unrecoverable data corruption. HTH, Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
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 )
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] SiteAccess and Roles
The Doctor What wrote: * Michael Bernstein ([EMAIL PROTECTED]) [001215 10:05]: The Doctor What wrote: Ok, then problem may be in your SiteRoot. What are the settings there? Really? I wouldnt't have suspected the SiteRoot. lesse Interesting. It now works, if I fill in the Base. Before, I had *nothing* in the SiteRoot access. Simply putting a Base in and bing-bang-boom, it works! Thanks for the help. Though the impression I got from the documentation is that this should have worked with the defaults Perhaps I don't understand exactly what Base and Path in a SiteRoot actually do Base replaces the portion of your URL comprised of the protocol and fully qualified domain name: 'http://www.servername.com' becomes 'http://www.yourhostedsite.com'. Path replaces the rest of the URL up to and including the folder containing the SiteRoot: '/hosted_sites/site1/' typically becomes '/' So the object that would have been published as 'http://www.servername.com/hosted_sites/site1/', now becomes 'http://www.yourhostedsite.com/'. Both of these settings affect such environment variables as BASEx and URLx which construct URL fragments for use in DTML. The Access Rule only redirects requests from one object to another by manipulating the stack, it doesn't affect the REQUEST namespace. You would generally be better off leaving the SiteRoot out, rather than putting one in and leaving it's properties blank. Does this help? Michael Bernstein. P.S. If you want to see exactly what the SiteRoot is doing, add a DEBUG method to your folder. the DEBUG method should contain dtml-var REQUEST. View the method both with and without the SiteRoot. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Help save my sanity (DTML-in string comparison)
Darin Lee wrote: Zopistas, I am trying to build a simple, 2 tier, tree-style navigation structure for my site. I have puzzled over the following code for hours, and it's just not working right. I have two loops, one that goes through the Parents, and when the parent matches the current folder, I go through the children (There are 2 scripts, one that resides one level up and presents a simple list of objects to click on) The following code lives in the child folders, and displays the parents and all of the HTML documents in the current folder. The output I am looking for resembles below. [snip] ¯-- BTW, I have tried the NFGNav product, but It doesn't work in my application (I suspect) because I am using transparent folders to organize things. I also want my NAV to start farther down the heirarchy (level 2), not from the root. Try ZNavigator, instead. HTH, Michael Berrnstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Fw: Zope.org feedback
Bill Anderson wrote: Bill Anderson wrote: ... The archives show that Loren was using this term for this usage by nearly a month. if nothing else, the timing of the application coinciding with the introduction of the term by Loren is at best suspicious. In fact, it occurs on the very day that Loren made the announcement of the howto. And according to the USPTO: Federal registration is not required to establish rights in a trademark. Common law rights arise from actual use of a mark. Generally, the first to either use a mark in commerce or file an intent to use application with the Patent and Trademark Office has the ultimate right to use and registration. Sorry, but 'breadcrumbs' as a description of various types of web-navigation features has been in use quite a bit longer than this. Try searching http://www.useit.com/ for the term 'breadcrumbs' and you'll come up with some documents dating to 1994. So Loren does not 'win', except that this Charles Knerr person has absolutely no claim on the term. Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] SiteAccess and Roles
The Doctor What wrote: * Michael Bernstein ([EMAIL PROTECTED]) [001214 01:06]: I read your access rule, and it seems like you've got it set up to ignore the gTLD, so that www.gerf.org and www.gerf.com etc. get routed to the same object automatically. Is that correct? Yes. I have several sites that use that feature, and none that don't. It's actually really handy, as it's one line in my siteaccess rule vs. several in my apache config. :-) Ok, then problem may be in your SiteRoot. What are the settings there? Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
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] SiteAccess and Roles
The Doctor What wrote: I have site access running, but I apparently don't fully grok roles. I have a directory layout like so: /ZopeRoot /site1 /site2 /site3 /user_acl(2) /user_acl(1) My site access rule is at: http://linuxasm.gerf.org:9673/siteid/view_source All the site[123] directories are SiteRooted and work fine. I read your access rule, and it seems like you've got it set up to ignore the gTLD, so that www.gerf.org and www.gerf.com etc. get routed to the same object automatically. Is that correct? Michael. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] LoginManager broken?
"Mayers, Philip J" wrote: Thanks, I'll take a look. Re: LoginManager - After a fast turnaround (confirming my ample faith in Open Source software) Magnus Heino pointed me in the right direction - the dtml methods and SQL objects need to be inside the UserSource folder, *not* the LoginManager folder as the Howto implies (or maybe I just can't read...). Can someone confirm that the SQL methods need to be inside the UserSource folder? (which is mildly annoying, but there we go...) I'm still having some problems getting multiple roles working, but it's behaving itself for now. Now all I have to do is solve my LIMIT problem... If you're having dificulties getting LoginManager to work with the local roles management interface, maybe this solution (which I only tested using LoginManger+Membership) will help: http://lists.zope.org/pipermail/zope-dev/2000-September/006953.html I ahve no idea how this would work with SQL users, but hopefully it'll give you a clue. HTH, Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
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] ZClass with images
Diego Rodrigo Neufert wrote: Anyone know how to put some images in ZClass? I have done things like putting ZClass with base class OFS:Image but with it I can only assing one Image do the object... I need to assign two or tree images do the object. I've been thinking about something similar myself. I'd like to create a ZClass/ZPatterns version of the Photo and ZPhotoAlbum products (or at least a reasonable equivalent). Specifically, I'd like to incorporate the functionality that, upon instantiation of the object, creates the neccesary sized versions and stores them. I'd like to use ZPatterns to be able to switch the storage between the ZODB, the file-system, or BLOBs in an RDBMS without altering the rest of the application. Any progress that you make would be very helpful to me. Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] jcNTUserFolder on 2.2.x
Toby Dickenson wrote: On Mon, 20 Nov 2000 14:20:41 -0800, "Andy McKay" [EMAIL PROTECTED] wrote: Is there an updated version or product similar to jcNTUserFolder (allowing NT authenitcation in Zope) that works in Zope 2.2.x? Or am I going to have to upgrade jcNTUserFolder? API changes in 2.2 (and future developments, like PTK) make custom user folders less attractive than they used to be. If you intend committing some time to this then I recommend something based on http://www.zope.org/Members/tsarna/LoginManager The simplest change would be to transplant the authentication code out of (jc)NTUserFolder and into LoginManager methods. However that would still only run on NT. Important: After you get authentication working the way you want it, you'll have to fix your LoginManager to integrate with the existing local roles machinery. Here's a link to help you out: http://lists.zope.org/pipermail/zope-ptk/2000-September/001739.html HTH, Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] New Zope.org
emf wrote: Zopatistas! Zope.org is finally living in its new home. Right now, you may be getting zope.org through the old apache, so don't be surprised if it's a tad slow. By late tomorrow, just about everybody's dns should have updated to the new IP address. If you want to know, do a nslookup www.zope.org: you should get 63.102.49.33 as your answer. When I finally wake up tomorrow, the first thing I'm going to do is start working on a write-up of what the new zope setup is all about. Was this the 'stealth' project? Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] FYI: Digital Creations secures $12M round of investment
Paul Everitt wrote: Hello Zope friends. At long last we at Digital Creations are able to publicly say it: we've closed a $12M round of investment: Congratulations, Paul. Vindication is sweet. Looking forward to DC's continued development as a company. Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Can't get dtml-tree to work in a sub-folder.
[EMAIL PROTECTED] wrote: Howdy Folks, I'm trying to make use of the dtml-tree gizmo and it only works in the root directory. I'm trying to create a dynamic navigation display so users can click their way through the sub-directories of files. Kind of a "Zope Explorer". Maybe this will help: http://classic.zope.org:8080/Documentation/HowTo/DTML/treetag Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
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] Python Zope Method as option for renamed Python Method?
Chris Withers wrote: Hamish Lawson wrote: Zope regards as a method a Zope Method? That would then give us Python Zope Method, Perl Zope Method, DTML Zope Method, SQL Zope Method, etc. Is it too late to add the option for Python Zope Method to the poll? All too long an unwieldy... glad to see the -lets have died. Sad to see neither Python Block nor Python Op(eration) seem so be gettign there since they most accurately describe what these things are, IMVHO... Thanks for the vote, Chris... :-) If the poll gets re-run, I'd like to add 'Python Code Block' as another contender. Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[Zope-dev] Paul comments on the PythonLabs Move
Check out his comments here: http://weblogs.userland.com/zopeNewbies/discuss/msgReader$831 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] siteaccess, hosting etc, sanity check
Jonathan Cheyne wrote: my various settings ... NameVirtualHost 111.222.333.444 VirtualHost 111.222.333.444 ServerName www.red.com ProxyPass / http://www.blue.com:8080/red ProxyPassReverse / http://www.blue.com:8080/red /VirtualHost then in /red we have a siteroot with the following title: base: http://www.red.com path: / Jonathan, Do you have an Access Rule set up in your root Zope Folder? Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] How to display PDF files
Alan Johnston wrote: At any rate, how do you get ZServer to send a 'raw' PDF file to the browser so that the browser's Acrobat plug-in can display it? I tried creating 'File' and 'Image' objects. That's obviously not it. 'File' should work. Are you naming the 'File' object with a .pdf suffix? HTH, Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[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] 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 maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
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 )
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] Determining permissions in a Product
Chris Withers wrote: When the dialog box pops up, hit cancel and see what authorization failed on. That should give you some clues as to what needs fixing. Incidnetally, I think this is a bit of a security hole. You shouldn't get told what you're not allowed to see, especially if it's 'cos you got your password wrong. If you see what I mean ;-) I see what you mean here, Chris, but wouldn't this come under the heading of a 'security through obscurity' hole? ie. you're saying that the system isn't obscure enough? Michael. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Bypass ZODB and use File System
Noah wrote: What we really want to do is to provide a second view to /var/www/htdocs for Apache. I understand that Apache won't serve up our dynamic content, but that's not important. Zope is just viewed as a better solution for managing our static documents. The problem we have in my organization is that there is a lot of resistance to my prototype Zope document management system due to the fact that everything is stored in ZODB. We think this risky -- possibly a data prison. The way my organization does it, is to manage the content within Zope, and to regularly run 'wget' on the server to replicate it all to static files, which are then served by Apache on another server. Doing that, plus regular backups of the Data.fs file (you're already making regular backups of your Apache based system, right?), and you should be guarded against any but the most catastrophicly unlikely disaster scenarios (you do have a disaster recovery plan, right?). wget is really a very easy way to get documents back out of Zope, and if your system is designed to do this as a matter of course (perhaps by using 'cron'), it should silence those particular criticisms. Also people don't want to change from their current habits of editing files via NFS or Samba mounted directories. My original plan was to allow them some sort of syncronization process, but now I think that would be crazy. Hmm. I guess it depends on what percentage of your users want to keep doing this. You can certainly combine LocalFS with the approach that I outlined above. I would make it a special case. Keep the CMS server separate from the Apache server, and only allow the mounted directories on the CMS server. I've found that people appreciate being able to manage their content from anywhere through a browser, and they tend to gravitate toward that as a matter of course, once it's there, if they're not forced to do it. In short, give people options, and see which ones they actually use. HTH, Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
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] Access Control vs Publishing Protocol
Chris Withers wrote: Toby Dickenson wrote: Those people were concerned that too many things were exposed via ZPublisher also My interpretation was that the issue is one of access control, not publishing protocol. I think the issue is that you can't limit the visibility of objects right now. You can limit their access easily enough (or more tortuously if you don't want people to access the bits of a page on their own (standard_*,etc) via a complex web of proxy roles and required permissions) but there doesn't appear to be any easy way to say "right, I want this object exposed for reading and writing via FTP and reading via HTTP, while this one shouldn't be URL traversable but I'd like to edit it via WebDAV and this method is for use via XML-RPC but really shouldn't be visible anywhere else.) It seems like this can be handled rather well by simply adding a 'XML-RPC access', a 'SOAP access' and a 'WebDAV access' set of permissions. we already have a 'FTP access' permission which works fine. Thse could then be matched with appropriate 'view' permissions as well. On a slightly different note, I think that the permissions list should be viewable in two more ways: A view where permissions are grouped into 'subjects', (for example all the ones I just mentioned should go into a 'access protocol' subject and possibly a 'view protocol' subject) and another view where permissions are grouped according to the roles that have them. These different views should all be on the same tab, with hyperlinks to switch between them (sort of like the 'local roles' screen is linked from 'security'). Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
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] 'Offline' mailhost
"Jan H. Haul" wrote: Each of these will be around 42 KByte large. Huh? Why that? you ask. Because in the header of each mail, the whole recipient list will be listed under To: or Cc: [snip] - privacy: You would not like to have "your" recipients end up on other people's mailing lists What about using BCC: ? Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Can Free Software Manage Your Web Site? http://www.inside.com/
"Steven D. Majewski" wrote: Inside magazine http://www.inside.com/ has a feature on Zope: "Can Free Software Manage Your Web Site?" Here's the direct link: http://www.inside.com/story/Story_Cached/0,2770,10617_13_32_1,00.html Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope, Threads and Signals
Wilkinson Charlie E wrote: It all began when I was a small child, but I'll skip ahead a bit I almost hate to say this, since your post is an interesting one otherwise, but please don't send HTML email to the list. Some of the people here don't use HTML-capable mail clients. Thanks, Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope, Threads and Signals
Charlie Wilkinson wrote: Michael Bernstein [EMAIL PROTECTED] wrote: Wilkinson Charlie E wrote: It all began when I was a small child, but I'll skip ahead a bit I almost hate to say this, since your post is an interesting one otherwise, but please don't send HTML email to the list. Some of the people here don't use HTML-capable mail clients. RANT target="Microsoft" I'm not a dummy. I didn't mean to imply that you were. [snip experience] BUT I CAN'T SHUT OFF HTML IN OUTLOOK TO SAVE MY MISERABLE F*ING LIFE [snip attempts to supress HTML] My suspicion is that some well meaning but deranged Exchange SMTP gateway server is doing the conversion, as there's a meta tag that says the HTML generator is Exchange. I've tried talking to the people who run the servers, but they are clueless and keep saying it's something I'm doing. [snip] /RANT Monday I'll check with our sysadmin and take a look at the Exchange Management UI myself. If I can identify the correct 'knob', I'll let you know, so you can pass this information along to your server admins. Meanwhile, you could use a free web-mail account, and just set the Reply-To or CC to your actual email address. I like netaddress.com (no Reply-To, though). Michael Bernstein. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
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: 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
"Phillip J. Eby" wrote: Ty and I use ZClasses because you can see your changes much more quickly than if you have to restart Zope. Basing your ZClasses on DataSkin makes the limitations pretty much disappear, from our point of view, because we never put any actual "implementation" code in our ZClasses: just domain logic, property sheets and UI (DTML) methods. All the actual mapping to/from data storage is carried out in the appropriate Rack or Specialist, neatly seperated. Occasionally we need an ExternalMethod in either the ZClass or the Specialist, but these are getting rarer as we find ways to create method-like helper objects that can be added through the Zope UI to accomplish common tasks. In general, we prefer that Python written outside of PythonMethods be re-usable for a variety of projects rather than a one-up for a specific application. YMMV. :) While I wouldn't say that there has been an actual 'paradigm shift' between the original RIPP presentation and ZPatterns, 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. 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. 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. 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 )
