- Zope - Zope lists

RE: [Zope] - Installation problem
by Jeff Bauer 08 Dec '98

08 Dec '98

Vanroose Wim writes: > When I try to log on When I use the passwd set in the > access file. I always get login failed. Are you using the default Zope settings or values you've set in AuthUserFile (or .htpasswd)? > Can somebody give more explanation on the > > RewriteRule in the Httpd.conf file????? # Zope configuration maps /Zope/ to the Zope.cgi PCGI script RewriteEngine on RewriteCond %{HTTP:Authorization} ^(.*) RewriteRule ^/Zope/(.*) /usr/local/apache/share/cgi-bin/Zope/Zope.cgi/$1 \ [e=HTTP_CGI_AUTHORIZATION:%1,t=application/x-httpd-cgi,l] The last line - RewriteRule - must be a single continuous line, i.e. remove the backslash, no line break. Your path may be different than above, and different that the default value mentioned in the install doc. The second argument to RewriteRule should be the absolute path to the pcgi info file, Zope.cgi. Check the Apache .conf files for the following: 1) No special rules for .cgi files 2) No additional restrictions imposed. Apache directives are sometimes counter-intuitive (turning on a switch can automatically turn off other switchs) so it's better to check the documentation rather than eyeballing the .conf files. Finally, make sure you stop/restart the httpd server after making any changes to the .conf files. Obvious, but often overlooked. Good luck, Jeff Bauer Rubicon, Inc.

1 0

Re: [Zope] - Misc questions & Suggestions
by Jim Fulton 08 Dec '98

08 Dec '98

Amos Latteier wrote: > (snip) > We've definitely thought about symbolic link like facilities which could be > useful for many things, not just page redirection. I'm not sure what the > current status on this idea is... The status is that someone needs to flesh out the specific requirements. The idea is pretty simple, but there are lots of devilish details. Consider the semantic differences between Unix hard and symbolic links, or these differences between these and Windows "shortcuts". And none of these systems use acquisition or sit behind a network protocol. :) > Another idea is some kind of tool that searches Documents and munges their > contents. A good place to start would be OFS.FindSupport.FindSupport.PrincipiaFind (soon to become an alias for ZopeFind :). This method, which is available from DTML does the searching part. This could, for example, let you grab the Documents that contain some string and modify their source. Amos, since you will need to do this to convert the Principia quick start database to the Zope quick start database, maybe you can work up and share a document that does this. > I desperately need such a tool for spell checking purposes. But > it could be used for link management and other purposes. This sort of tool > would be easy to write. I also definiately agree that specific support, for link management work be a cool thing. Prototypes would be a good place to start. > If you're really crazy, you could manage links by using properties and > reference them as vars in your documents. Then you could easily change a > link definition in one place and not worry about any broken links. > > >4) What does OFS stand for? What's an acronym doing in a world of TwoWord > > names? > > I think it means "Object File System". There are probably lots of names > that could be improved. I'm not looking for more work. While names like App (which is a hold over from a pre-Principia framework) and OFS (which reflected one of the many early names for Principia) are a bit crufty, I don't expect to change them anytime soon, as there are lots of pickles that use them. It's possible to work around this, but there are more important things to do right now. :) (snip) Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

2 1

Re: [Zope] - Yet another stupid question: image folders
by Phillip J. Eby 08 Dec '98

08 Dec '98

At 04:40 PM 12/7/98 -0500, Christopher G. Petrilli wrote: >On Mon, Dec 07, 1998 at 04:35:43PM -0500, Phillip J. Eby wrote: >>  > >This works, but I'm gonna whine that it's WAY too much typing :-) Well, if you do this a lot, define a 'logo' document which contains it, then everywhere else you'll only need to call it once. If you want it to be more dynamic, make a 'showSubImage' document and make it say:  And then call it with:  Unfortunately, this is actually longer than the original 'with' version, but at least it shows off some DTML hacking techniques. :) >Prefferable (though currently illegal) would be: > > Ugh. Please don't go there. >Somehow I think this could be useful for a lot of things... just don't >ask me what else. Alas, I think this is how Perl got the way it is. Yep. :) Always be wary of taking an initially simple and clever idea and then beating it to death with a dead horse, or something like that. :)

3 3

Re: [Zope] - python + RedHat 5.1
by Michael Bailey 08 Dec '98

08 Dec '98

> On Mon, Dec 07, 1998 at 09:22:23AM -0800, Scott Robertson wrote: > > > I am running Redhat 5.1 and I am having the same problem when I compile. > > I'm suspecting that the python 1.5 RPM is missing some component. > > My system does not have a /usr/lib/python1.5/config directory. > > Has anyone else been able to get this to run on a RedHat 5.1 system? > > > > Will I have to compile python myself? Andrew's earlier post answered this question for me. I grabbed python-devel from http://andrich.net/python/download.html and this solved the problem for me. Andrew M. Kuchling wrote "Be sure that the 'python-devel' RPM is installed; it contains the config/ subdirectory and the other stuff required to compile Python modules." -- Michael Bailey

1 0

RE: [Zope] - newbie PCGI problems
by Jeff Bauer 08 Dec '98

08 Dec '98

Peter J Ulintz writes: > My system is a Sun sparc server running Solaris7 and > Python1.5.1. Installed Apache1.3.3 (first time for me) > and ran the w_pcgi.py script, which seemed to work correctly. Congratulations for making it this far along, especially if you've just started using Apache. > NEWBIE QUESTION I: > Exactly where do you put the mod_rewrite config info? I > tried putting it in the normal three .conf files and got > errors. I DID compile the server with the mod_rewrite > included. The Rewrite directives for Apache normally go in httpd.conf. Actually the Rewrite directives should only affect authorization, so if you are denied access *after* the user name and password dialog appears, everything else with PCGI is probably working. > Decided to try out the system anyway, running the > http://myservername:80/cgi-bin/Zope/manage command and > got errors (Can't remember the exact one). I checked > the pcgi.log file, and noticed that I was getting tracebacks > indicating... > > "File > "/export/home/pulintz/Zope-1.9b1-src/lib/python/BoboPOS/SimpleDB.py", > line 227, in open > except: raise IOError, 'could not open ' + file_name > ImportError: (<class exceptions.IOError at ab3d8>, 'could not open > /export/home/pulintz/Zope-1.9b1-src/var/Data.bbb.trans')" > > So I changed the permissions on the Data.* files /var directory > (yes the var directory had full permissions), and got the following > traceback error... Ah, this points out a potential problem. If you start using Zope with ZopeHTTPServer under your account, then it's possible that the database is no longer accessible through your web server. This is something we should document better, because it represents a natural progression of tasks. > File > "/export/home/pulintz/Zope-1.9b1-src/lib/python/ > Products/sample/Product.py", > line 24, in ? > import OFS.SimpleItem, Persistence, Acquisition, AccessControl.Role > ImportError: (<class exceptions.ImportError at ab540>, > 'No module named Persistence') > Went into the Product.py file and changed "Persistence" to > "BoboPOS.Persistence", and tried to bring up zope in the > browser again. I got the authentication window! But I > couldn't authenticate, getting the error message concerning > the authentication headers. Okay, you've got the LRP running. As mentioned above, if you see the authentication window, PCGI's job is essentially complete. The problem is likely to be your RewriteRule. Note that you may have to change the path from what's specified in the INSTALL file. A common error is for users to forget to specify the absolute pathname. Changing the code in Product.py is a no-no at this stage unless you're doing something benign (e.g. log file or MrCreosote) because you're simply hiding a problem that will be more difficult to track later. See below. > Around that time, the email from Jeff Bauer came thru > indicating that removing the pcgi.* files from the /var > directory might be good, so I did that, and that's > all I remember doing at that point. But the next time > I tried to bring up Zope, I got the "!Temporarily Unavailable" > message, with the message "(103) unable to verify if > process is running" Uh-oh. Did you remember to kill the running LRP? My earlier advice to Mike P. applied to his condition (not being able to launch the process). As long as you killed the running process (if there was one) before removing the files it's okay. It actually doesn't really matter, but you don't want stale processes clogging up your system. > Drag... Guess I've gotta go and read those documents on > Jeff's site about pcgi. Running the pcgifile.py from the > /cgi-bin gives... > > PCGI info file: /export/home/pulintz/Zope-1.9b1-src/Zope.cgi > PCGI wrapper: /export/home/pulintz/Zope-1.9b1-src/pcgi/pcgi-wrapper > error attempting: 'from cgi_module_publisher import publish_module' > status: FAILURE This provides us an important clue, although it's slightly misreported and you actually had it available in your earlier traceback. (Zope was released before pcgifile.py could be updated; to be remedied shortly.) The pcgi_publisher.py module is actually trying to import publish_module from ZPublisher. Since your problem (authentication aside) is essentially one of not being able to import the correct module, for the time being let's put PYTHONPATH in your Zope.cgi info file: PYTHONPATH=/usr/local/bin/python:. If the solution still isn't obvious, you can try to expedite things by creating a test cgi file, TestZope.cgi: #!/usr/local/bin/python print "Content-type: text/html" print print "Looks OK" Get TestZope.cgi working and then add some import statements, placed just before print "Looks OK", e.g.: from ZPublisher import publish_module As it breaks, you can add to your import path by iteratively doing the following, placing the sys.path.append just ahead of importing publish_module. import sys sys.path.append('/export/home/...') The step above shouldn't be necessary, but it helps to define a small test case so that you can narrow down the real problem. And it's better than sitting there staring at your screen <wink>. > any advice in the meantime would be appreciated (besides > "You're not worthy-- go back to Perl") Worthiness aside, nobody deserves to suffer that fate. Hang in there, Jeff Bauer Rubicon, Inc.

1 0

- Database difficulty
by A.M. Kuchling 08 Dec '98

08 Dec '98

So far Principia products have only been written by experienced developers, but with random bozos messing around with buggy partially-implemented Products, the management code is going to have to be made more resilient against bad objects. Here's an example traceback I got: Sorry, an error occurred. Traceback (innermost last): File /home/opt/zope/lib/python/ZPublisher/Publish.py, line 861, in publish_module File /home/opt/zope/lib/python/ZPublisher/Publish.py, line 583, in publish (Info: /manage_main) File /home/opt/zope/lib/python/Globals.py, line 222, in __call__ (Object: manage_main) File /home/opt/zope/lib/python/DocumentTemplate/DT_String.py, line 502, in __call__ (Object: manage_main) File /home/opt/zope/lib/python/DocumentTemplate/DT_In.py, line 675, in renderwob (Object: objectItems) File /home/opt/zope/lib/python/OFS/SimpleItem.py, line 144, in title_and_id (Object: Item) AttributeError: id The problem in this case arose from a syntax error in the code for the product, which made the module import fail. When I changed title_and_id(self) to: t=self.title try: i=self.id except AttributeError: i="No ID!" + repr(self) return t and ("%s (%s)" % (t,i)) or i Zope correctly displayed that this object was broken. I'm not sure if this suggested change is the right one, but it worked for me... -- A.M. Kuchling http://starship.skyport.net/crew/amk/ You have called me here, Haroun. It is unwise to summon what you cannot dismiss. -- Dream, in SANDMAN #50: "Ramadan"

1 0

- Zope Site news updates
by Amos Latteier 08 Dec '98

08 Dec '98

Hi All: Wow, the level of excitement and discovery is overwhelming. I can barely keep up. I just added a couple features to the Zope site, that hopefully can in small ways help us keep up: * You can now add news and tips to the site with an online form. The items don't immediately go live, I get to review them first ;-) * You can search news and tips. So if you have any insights or announcements that you want to share, please submit those tips and news items. Otherwise I am still cranking on documentation and other projects to try and make your lives easier. Thanks to everyone who is taking the time to answer questions! As always, send me your suggestions and complaints. I try to read them all, even if I don't have time to reply to everything right away. Thanks. -Amos

1 0

RE: [Zope] - Yet another stupid question: image folders
by Jeffrey Shell 07 Dec '98

07 Dec '98

> I'm looking for an easy solution, BUT... for example, in Frontier, yo > ucan type something like: > > #image "blah.gif" > > And it will insert everything needed (including H/W tags). This works > even if you happen to have things stored in a subdirectory if I recall > (it's been a while). > > I know that most sites Zope has been used for probably aren't that > graphically intense, but a lot that I work on are, and I'd be > stuck with > nearly a billion of these refernces or writing custom code > that probably > is identical to other people's custom code. > > For the object repository to be useful, it has to be able to > SIMPLIFY my > life, not complicate it :-) This is a heavily double-edged sword, as we've found a few times ourselves. As you start to simplify too much, being able to use and re-use something in different situations becomes very difficult. On the other hand, if you make things too general, they become too hard to use. :/ > So since I'm a glutton for punishment, why wouldn't a tag: > >  But then you lose control over things like borders, javascript event handlers, imagemaps, style sheet properties, and all of the billions of combinations of tags. If you're doing a graphic intensive site, I would imagine that you would want finer control over your images and to be able to take advantage of HTML that Zope-Image developers can't keep up with. WebObjects is engineered for these types of dynamic widgets, Zope (like ActiveServerPages) isn't. So while you don't get a single-line #var insert, you do get tight control when you need it. For example, I've tried a few times to come up with a SELECT list tag that would select a value already given by the user. Sounds simple, right? Not with the flexibility I've often found myself yearning for (having to compare a possibly set value against one or two other lists coming from multiple sources and setting the presentation value and the widget value). The only major widget we have is the tree tag. And, while it brings incredible simplicity to generating hierarchical "tree" objects in HTML, there have been many times where it's grown with new parameters and more new parameters and even more new parameters to cover more and more of the different ways Trees needed to be rendered. Again, this is a fairly general-purpose widget. Specific widgets like images or select tags are tips of very very big icebergs.

2 1

- Updated win32 PYD files
by David Ascher 07 Dec '98

07 Dec '98

I've added the cPickleCache.pyd file to the unofficial win32 patches located at: http://www.zope.org/Download/Contrib --david ascher PS: I'd suggest to email me w/ win32-specific bug reports due to the use of said patch, instead of the main list (after all, Zope isn't supposed to work on Win32 yet =)

1 0

Re: [Zope] - Yet another stupid question: image folders
by Christopher G. Petrilli 07 Dec '98

07 Dec '98

On Mon, Dec 07, 1998 at 04:48:41PM -0500, Brian Lloyd wrote: > > I see what you're saying now. I think this boils down to > the usage of the __str__ method of Image objects: > > def __str__(self): > return '<IMG SRC="%s" ALT="%s">' % (self.__name__, > self.title_or_id()) Right this is what I was tweeking the other night trying to get this to work, but couldn't figure out how to find it's hierarchy. > I believe that this was added as a little convenience, > rather than a universally applicable thing. The problem here > is that you want (need) control over the SRC attribute. I would > suggest that it's better all around to simply use a bit of > DTML like: > > <img src="images/logo" alt="" > width="" ...> Maybe I'm lazy, but this seems like an AWEFUL lot of work that can't be automated by site tools (ney Dreamweaver), and that shouldn't be needed to be typed 5000 times when it's nearly always identical. I understand I'm looking for an easy solution, BUT... for example, in Frontier, yo ucan type something like: #image "blah.gif" And it will insert everything needed (including H/W tags). This works even if you happen to have things stored in a subdirectory if I recall (it's been a while). I know that most sites Zope has been used for probably aren't that graphically intense, but a lot that I work on are, and I'd be stuck with nearly a billion of these refernces or writing custom code that probably is identical to other people's custom code. For the object repository to be useful, it has to be able to SIMPLIFY my life, not complicate it :-) So since I'm a glutton for punishment, why wouldn't a tag:  Be allwoed to insert it's location in full, rathre than relative (which should never break anything I can thinik off off-hand), as well as it's ALT and H/W tags (which maybe should be stored in properties now that I think about it, and only updated when the image is inserted into the database/updated, lower overhead). Humor me here :-) Chris -- | Christopher Petrilli | petrilli(a)amber.org

3 3