November 2000 - Zope-Dev

Re: [Zope] still problems w/ SiteAccess 2.0.0b3
by The Doctor What 09 Nov '00

09 Nov '00

* The Doctor What (docwhat(a)gerf.org) [001109 15:18]: > I'm curious, you posted a message about SiteAccess. I have the same > problem, with Debian (Zope 2.2.2 and I've tried SiteAccess 2.0.0b3 > and b4). > > It producing the same errors you have, but in addition, I have this > info from the stupid log file: > 2000-11-09T20:09:18 ERROR(200) Zope Couldn't install SiteAccess > Traceback (innermost last): > File /usr/lib/zope/lib/python/OFS/Application.py, line 488, in install_products > (Object: ApplicationDefaultPermissions) > (Info: SiteAccess) > File /usr/lib/zope/lib/python/Products/SiteAccess/__init__.py, line 12, in initialize > File /usr/lib/zope/lib/python/App/ProductContext.py, line 323, in registerHelp > OSError: [Errno 2] No such file or directory > > > I have no idea what's going on, and any help from you or the zope > mailing list would be appreciated. I figured it out. With a little help from my friends. This product is missing a 'help' directory. I'm not sure if this is a debian feature or not, but attached is a patch to let zope load it whether the directory exists or not. I basically wrapped a try around the part of the code that looks for the help directory and files within it. This is the file App/ProductContext.py, btw. I'll see about fixing SiteAccess (and Plugin, which has the same problem) for Debian. Ciao! -- Computers are useless. They can only give you answers. -- Pablo Picasso The Doctor What: "What, Doctor What" http://docwhat.gerf.org/ docwhat(a)gerf.org KF6VNC

1 0

DynPersist for Windows, ZPatterns 0.4.3b1 and Zope 2.2.x
by Chris Withers 09 Nov '00

09 Nov '00

Hi, Just went through the fun of compiling this so thought I'd mail it to the list in case anyone else wants it... Also noticed the Pluggin product is missing a /help folder in the distribution which makes registerHelp() barf unpleasantly. Adding an empty directory of that name makes the problem go away. cheers, Chris PS: Rename the file back to DynPersist.dll and stick it in the ZPatterns directory.

3 2

ZPatterns: Non-ZODB storage and Racks
by Roch'e Compaan 09 Nov '00

09 Nov '00

In Rack.py I noticed the following: a = self.loadAttrib if not a: slot = self._writeableSlot(key) slot[SelfKey] = item.aq_base # strip acquisition wrapping item._setSlot(slot) # Not needed for non-ZODB storage If item._setSlot set is not needed for non-ZODB storage should I subclass rack and override createItem? Roché

4 10

Python Product Style - on-the-fly objects to DTML
by Jim Washington 09 Nov '00

09 Nov '00

Hi, all I have a project going that requires the users to fill-out many different tabular data forms. So, I thought I would develop yet another table-generator. The main class (descended from OFS.SimpleItem) has a reorderable list of information (MT_ColumnInfo(Persistent)) about the columns (title, name, type, size, etc.) and another reorderable list of information about the rows (MT_RowInfo(Persistent)) (title, name), so that the column names and row names can be put together and I do not have to worry about getting R*C names right for each table. Anyway, I do not want to return any of these classes to DTML for processing. I want another class, CellInfo, which has the concatenated row and column names as name, and the type, size, etc. information from the Column information. A list of these with the title of the Row would be a row_data, so what I have to work with in DTML is the column_headings list and a list of row_data objects containing a list of CellInfos. All of these can be generated on-the-fly, so should not need to be descended from a Persistent Class. Less stuff to change if the table needs to be modified / reordered. But: In my usual trial-and-success blundering about, I find that unless these objects participate in the security system, I get "the login window that will not leave". So, I descend these objects from OFS.SimpleItem and give them default __ac_permissions__. Everything works as expected. Looking closer, I see that the thing really working is: descent from AccessControl.Role.RoleManager and __allow_access_to_unprotected_subobjects__=1. So I make these modifications, and everything seems fine. Allowing access to unprotected subobjects is cool, since these are non-persistent. Now for the question: What happened when I created un-attached Persistent descendents on-the-fly while testing earlier? I presume they garbage-collected away when I was done with them. Is this correct? I have a nagging worry about ghost objects and the types of programming errors that might create them. -- Jim Washington

1 0

Cache parameters
by Andy McKay 09 Nov '00

09 Nov '00

Just wondering what kind of cache parameters people run on their Zope installation. It would seem running a high target size and maximum time between accesses would speed up those requests it can find the cache, but not cached request take longer since more RAM is used in the maintaining of the cache (guess). Has anyone found a sweet spot away from the standard, I guess of course it all depends on the individual Zope site, this one is particulary ZCatalog heavy. Or should I just leave it at the default, which I found seems to work fine. -- Andy McKay, Developer. ActiveState.

2 1

RE: [Zope-dev] JPython Product?
by Bjorn Stabell 09 Nov '00

09 Nov '00

Somehow I think the other way around would be even more interesting: a Java application server accessing Zope (Jope?). The platform market is really tough, and competing with Java isn't easy. If you can't beat them, join them... I guess there are millions of reasons why it can't be done, though? -----Original Message----- From: Casey Duncan [mailto:casey.duncan@state.co.us] Posted At: Wednesday, November 08, 2000 23:20 Posted To: Zope Developer Conversation: [Zope-dev] JPython Product? Subject: RE: [Zope-dev] JPython Product? Steve: That is good to know, being a Mac fan myself. I'll have to play with and test the different browsers on the client side as well as server-side jdks. >From what I have learned so far on the server end, the project seems reasonably feasible. I think the interesting part will be creating the precise dividing line between the JPython and CPython worlds. I doubt much JPython will exist in the product excepting some "glue" to get Zope/CPython to interact with it in a robust way. That will probably be the fun part. Thanks for the comments, Casey D. -----Original Message----- From: Steve Spicklemire [mailto:steve@spvi.com] Sent: Wednesday, November 08, 2000 5:33 AM To: casey.duncan(a)state.co.us Cc: zope-dev(a)zope.org Subject: Re: [Zope-dev] JPython Product? Hi Casey, I think this is a fine idea. The main thing that keeps me from doing it is that JPython doesn't work on Netscape (Mac) and so (at this point at least) I can't use it, unless I have a context where I can insist that users use a particular browser. The other annoyance is the long download time for the JPython implementation.... The other annoyance is the general flakiness of Java VMs out there.... But.. I think the concept is a good one.. and once the JPython implementation is cached it should be pretty fast. Then you just have to worry about all the JVM bugs. ;-) good luck! -steve _______________________________________________ Zope-Dev maillist - Zope-Dev(a)zope.org 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 )

1 0

Re: Problems with LoginManager 0.8.8b1
by Phillip J. Eby 09 Nov '00

09 Nov '00

Jeff, The behavior is exactly the same with a "plain" Zope User Folder. It also has nothing to do with acquisition, at least not in the way you think. The problem is that a user who is defined in a subfolder is *not* granted roles to any folder above them. This means that they have no access to "standard_html_header", unless it is set to be viewable by Anonymous. Hope that answers your question. At 11:50 AM 11/7/00 -0500, Jeff Hoffman wrote: >Phillip and Ty, > >I posted this to the Zope list two to three days ago. No one has >responded, so I am writing you directly in the hopes that one of you >may have some insight on my problem. > >If I can do anything to help you narrow it down, such as tarring up >my Zope install and sending it to you (with my ZODB and products), >let me know. > >Thanks, > >--Jeff > >--- >Jeff K. Hoffman 704.849.0731 x108 >Chief Technology Officer mailto:jeff.hoffman@goingv.com >Going Virtual, L.L.C. http://www.goingv.com/ > >---------- Forwarded message ---------- >Date: Sun, 5 Nov 2000 16:02:14 -0500 (EST) >From: Jeff Hoffman <jeff.hoffman(a)goingv.com> >To: zope(a)zope.org >Subject: [Zope] Problems with LoginManager 0.8.8b1 > >Hello, > >I am having an odd problem with LoginManager 0.8.8b1 and am writing the >list in the hopes that someone can either help me out, or confirm that >I've encountered a bug. > >I am running Zope 2.2.2 with Python 1.5.2 on a Linux box. I installed >LoginManager as described, and compiled DynPersist and so forth for >ZPatterns. All seems to be working well. > >I created a temporary folder called 'sandbox', inside of which I >instantiated a LoginManager. In its UserSource (a Generic User Source), I >created four Python Methods (with Python Methods v0.1.7): > > --- > userAuthenticate > <params>self, REQUEST, username, password</params> > > if username == 'XXX' and password == 'XXX': > return 1 > else: > return 0 > --- > userExists > <params>self, REQUEST, username</params> > > if username == 'XXX': > return 1 > else: > return 0 > --- > userDomains > <params>self, REQUEST, username</params> > > return [] > --- > userRoles > <params>self, REQUEST, username</params> > > if username == 'XXX': > return ['Manager', 'Member'] > else: > return ['Member'] > >Once done, I pointed my browser to http://myhost/sandbox/index_html. This >method is a standard DTML Method, inluding standard_html_header and footer >and putting some text in the middle. > >I get the following error: > >Traceback (innermost last): > File /usr/local/zope/lib/python/ZPublisher/Publish.py, line 222, in >publish_module > File /usr/local/zope/lib/python/ZPublisher/Publish.py, line 187, in >publish > File /usr/local/zope/lib/python/Zope/__init__.py, line 221, in >zpublisher_exception_hook > (Object: Traversable) > File /usr/local/zope/lib/python/ZPublisher/Publish.py, line 171, in >publish > File /usr/local/zope/lib/python/ZPublisher/mapply.py, line 160, in >mapply > (Object: index_html) > File /usr/local/zope/lib/python/ZPublisher/Publish.py, line 112, in >call_object > (Object: index_html) > File /usr/local/zope/lib/python/OFS/DTMLMethod.py, line 172, in __call__ > (Object: index_html) > File /usr/local/zope/lib/python/DocumentTemplate/DT_String.py, line 528, >in __call__ > (Object: index_html) >KeyError: standard_html_header > >Zope can't find standard_html_header. I am guessing the acquisition path >is getting hosed somewhere along the way. If I simply delete acl_users >from sandbox (my LoginManager), index_html works fine. Moreover, it is not >just standard_html_header that I can't acquire. I created a DTML Method >called foo, and could not acquire it, either. > >Any ideas? > >--Jeff > >--- >Jeff K. Hoffman 704.849.0731 x108 >Chief Technology Officer mailto:jeff.hoffman@goingv.com >Going Virtual, L.L.C. http://www.goingv.com/ > > >_______________________________________________ >Zope maillist - Zope(a)zope.org >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 ) > > > >

2 1

DataSkins containing DataSkins
by John Eikenberry 08 Nov '00

08 Nov '00

I have an idea for getting around my ConflictError problem without a major redesign. But it involves DataSkins containing DataSkins. I have a few questions about this... The base DataSkin will be in a Rack. Would there be any issues in making the embedded DataSkins (contained on the base DataSkins) use this Rack as well? Seems like it might result in the confusion about which DataSkin a PlugIn on the Rack worked with. Would it be better to use Customizers in some way... either have the base Dataskin or perhaps the Specialist also inherit from the Customizer? Phillip, I think you've considered this (didn't you once mention converting PropertySheets to DataSkins). What issues do you think I should be aware of in planning for this. I tried to dig around in the list archives, but I couldn't come up with a search pattern with any applicable hits. So I'm sorry if I'm reiterating something already discussed. Thanks in advance for any help... -- John Eikenberry [jae(a)zhar.net - http://zhar.net] ______________________________________________________________ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin

3 2

ZPatterns, MySQL, Full Text Searching
by Chris Withers 08 Nov '00

08 Nov '00

Hello, I've read that ZPatterns and ZCatalog don't interact too well and I was wondering if this is also true of the new ZPatterns release. I might be looking to move something to ZPatterns so that it can get all benefits of Zope's security system and things like the Catalog, obviously if the Catalog doesn't work with ZPatterns, that's a bit of a problem :-S On a related note, has anyone thought of using MySQL's new full text searching to implement the Catalog interface? Has anyone thought of or actually made the Catalog stuff into an interface so people can implement other options to ZCatalog? cheers, Chris PS: Is there a ZPatterns demo/tutorial around anywhere? How should I start getting into ZPatterns? What should I read? Where should I start? (The four most common ZPatterns FAQ's if I'm not mistaken ;-)

3 2

JPython Product?
by Casey Duncan 08 Nov '00

08 Nov '00

I have been toying with the idea of creating a Zope product for creating JPython applets within Zope. I thought this might be a way to increase the capabilities of Zope on the client-side while remaining firmly grounded in Python and simultaneously giving me an excuse to play with JPython and maybe create a useful Zope product too. I wanted to throw this out to the group to see if others thought this was a worthwhile capability. The basic idea would be to write JPython scripts and applets in Zope either via the web or otherwise and automagically "compile" them into transparent .jar files that are served to the client on request. Sounds so simple! Right?? Somehow I doubt it will be, but... >From what I see no one has done this so I figure at least one of following is true: 1. Nobody thought of it or felt compelled to act on the thought. 2. Its gonna be hard to do. 3. Somebody else already did it and I don't know about it. 4. The idea blows. Any thoughts on this idea, + or - are appreciated. -Casey D.

3 3