March 1999 - Zope - Zope lists

passing REQUEST.form to frames
by Hannu Krosing 09 Dec '99

09 Dec '99

What is the correct syntax for passing form data to child frames of a frameset ? I would like to pass form fields that is submitted to frameset to child frames. Is there any alternative built-in syntax to using an ugly construct like this : =& ------------------ Hannu

2 1

- FYI: Zope Roadmap for next two months
by Paul Everitt 23 Jun '99

23 Jun '99

Howdy all. I've attached below a quick snapshot of things happening for Digital Creations and Zope. The roadmap finally allows me to answer some of the questions coming up here in the Zope community. --Paul Paul Everitt Digital Creations paul(a)digicool.com 540.371.6909 Zope Roadmap For about two months I have made attempts to write down a roadmap that described future directions for Zope. I could never find the right format for detailing the items, though. No one likes to go on record making promises. I settled on the following format as a good compromise that allows me plenty of wiggle room. Each of the items below has a number between one and three in front of it. A one means we are quite likely to do it in the next two months. A three means we have done some work on it and are likely to do more work on it, but don't expect too much progress. The easiest way to get us to change priorities, of course, is through consulting. Many of the items in the list are in support of existing consulting projects. I'll start with Digital Creations, as some of the items we are looking at impact the Zope community. o (1) Hire seven more folks. I expect us to have concluded employment contracts with another seven people by the end of February 1999. We are pretty busy on consulting contracts right now and, as you can see, have quite a backlog of Zope work to do. o (1) Get ten case studies online. Just about everybody new to Zope and/or Python wants to see something done with it. We *have* done interesting work, we just need to package it up to make the case studies and testimonials visible. By the way, giving us some good words to put on the website about Zope really, really helps us convince newcomers to try it out, so pitch in! o (1) Relocate offices. By the end of January we will have switched offices as we need a lot more space. Needless to say we have a disruption facing us but we are doing a good job of managing it so far. o (1) Business plan for 1999. There are a couple of trends that are emerging on the scene in 1999, most notably the mainstreaming of open source. We would like to position ourselves to capitalize on these trends. Thus we are reviewing our business plan and having a board vote first week of February. o (1) Start a Zope Hosting Provider program. I have a page mostly finished for a signup and have two companies that have indicated serious interest. The following is a list of initiatives in the Zope area that are on our radar, though some rely on continued funding from consulting projects, which can be tough to predict: o (1) Tabula and indexing structures. We are going to begin a slow process of moving pieces of Tabula into Zope. The Zope 1.10 release will put the BTrees, integer sets, and indexing machinery into Zope. Tabula itself will be available just afterwards for a small audience of those willing to work with us on it. Over time this will mean Zope will scale up much, much more. In the nearterm it allows the Zopespot project to get kicked off. o (1) Start Zopespot. We have been planting seeds for a while to do a "Slashdot" in Zope. I have been working on a requirements document off-and-on for the last two weeks. More importantly, Ken Manheimer was hired to be the shepherd for this project. More to follow in a separate post. o (1) Release overhauled versions of the four main documentation artifacts. We hope to have by the end of this week new, overhauled versions of the Zope Manager's Guide, the DTML guide, and the SQL Methods (formerly Aqueduct) guide. When Tabula makes it out we will publish its documentation. o (1) Zope 1.10 released. Zope 1.10 will include: - BTrees and integer sets - The SearchIndex package which has a number of indexing classes, including classes for field indexes and text indexes. - Property management broken out into a separate mixin - Properties DTML Documents, Images, and Files - Image patches provided by Ty Syrna to allow size attributes - New absolute URL feature to allow images to referred to from different folders more easily - Bug fixes, plus anything else I've forgotten o (1) Relocate zope.org. Starting this week we are relocating the website which has a big fat pipe to the Internet, as well as people more talented than us to look at it. We'll make a separate announcement about this. o (1) Public CVS server. When Ken gets here I imagine he'll move pretty quickly to getting a public repository available using CVS or Perforce. o (2) Confera released. When the machinery from Tabula goes back into Zope we can brush up Confera and release it. Confera provides threaded discussions that include moderation, full-text searching, and more. Documentation was also written for it so we'll brush that off as well. o (1) WebDAV. Brian Lloyd has made quite a bit of progress on WebDAV. Our goal is to get Zope's hat in the ring for WebDAV as soon as realistically possible. o (1) Zope/Medusa with FTP. As you may have seen on Friday, Amos and Jim have worked with Sam to iron out an architecture document for Zope/Medusa. We should have an alpha release this month of Zope/Medusa with PCGI, HTTP, and FTP implemented as Medusa handlers. o (2) A formal Zope query language. Adding a standard query language, such as OQL or XQL, has recently become pretty important. I hope that we will show some progress on this over the next month or two. o (2) Zope2 beta with full concurrency. It is very important that we make progress on the architecture described by Jim's "BoboPOS3alpha1" paper. o (2) XML. Zope is a great fit for XML, even better with the machinery from Tabula going in. We also see XML becoming the basis for other initiatives, such as WebDAV and RDF. However, we just can't squeeze out the time to dive in deep. Rather, we'd love to see more community progress like that which popped up this weekend. o (3) Offer Collector. A good number of people have asked about contracting with us to get the Collector software for tracking bugs reports, feature requests, and more. Thus we might have a Zope-based solution available and packaged that our customers can drop into their sites. o (3) Replication. Being able to copy the contents of a main site to a local site, make changes while offline, then replicate them back up is a compelling opportunity for Zope. And it isn't that unrealistic, as some of the machinery is there already in the undocumented manage_exportHack operation. However, until it pops up on a consulting gig I doubt Digital Creations will return to it. o (3) Progress on "Python Interfaces", http://www.foretec.com/python/workshops/1998-11/dd-fulton-sum.html. Many of the initiatives we start around here seem to cross territory where we wish we had interfaces. Of course I might have forgotten a thing or two here or there. I'm sure you folks will let me know if I have. :^)

2 1

- ZAP for Win32?
by Michael Bernstein 13 May '99

13 May '99

Will there be a ZAP (Zope Apache) package for win32 on the zope site anytime soon? Michael Bernstein.

4 4

Zope+FreeBSD.???
by Daren Sefcik 16 Apr '99

16 Apr '99

Has anybody gotton Zope and FreeBSD to work..?? I cannot get it working and have read some posts to same extent, if anybody has it working could you be kind enough to share your setup details?? TIA, Daren

2 1

Zope.cgi -> mod_zope
by Oleg Broytmann 10 Apr '99

10 Apr '99

Hello! Is there any plan to make complex "Apache + Zope" even more efficient by making Zope.cgi a module (mod_zope, let's name it, or mod_pcgi)? Oleg. ---- Oleg Broytmann National Research Surgery Centre http://sun.med.ru/~phd/ Programmers don't die, they just GOSUB without RETURN.

2 2

Re: [Zope] sqltest vx. var
by Jeffrey P Shell 10 Apr '99

10 Apr '99

>From: Philip Aylesworth <zopelist(a)regalint.com> > I'll correct myself here. I was thinking of the  tag. I > don't know what  does that  or >  won't do... A _very very_ nice feature of #sqltest is the 'multiple' feature. For example: SELECT * FROM inbox WHERE  If doc_status is passed in as a single value, like "foo", the SQL statement will be rendered as:: SELECT * FROM inbox WHERE doc_status='foo' BUT!!! (this is where it gets good), if doc_status is passed in as a list/sequence, like ["foo", "bar", "drop", "ship"], it will be rendered as:: SELECT * FROM inbox WHERE doc_status in ('foo','bar,'drop','ship') This is an _extremely_ handy feature of #sqltest. Prior to #sqltest, doing the above might be like: SELECT * FROM inbox WHERE doc_status in (  '' , ) (#else used to be used where #unless is used today). The above code also always required doc_status to be passed in as a sequence. #sqltest is smart enough (I believe - i've never been bitten by this) to detect the difference between strings and lists. I've used #sqltest with multiple many times with Acquisition where a folder property would define part of a SQL statement. That property in some cases would be a single value, in other places it would be a tokens or lines property. So, in otherwords, you get the type checking, the multiple, the optional, etc... with #sqltest that you don't get otherwise. About the only problem is that #sqltest currently doesn't do not-equals or "not in (...)". .jPS | jeffrey(a)digicool.com zope, through the web. www.zope.org

3 2

multiple SUBMIT buttons for same method, with parameter
by Piers Lauder 05 Apr '99

05 Apr '99

I can use the following in a DTML document to call a specific method: <INPUT TYPE="submit" NAME="mymethod:method" VALUE="Delete this item"> But what if I wanted to have lots of them? I'd like to have multiple SUBMIT buttons, all referring to the same method but diffentiated by parameter - possible? Ie: something like: <INPUT TYPE="submit" NAME="mymethod:1:method" VALUE="Delete item 1"> passing the parameter '1' to 'mymethod', and then later <INPUT TYPE="submit" NAME="mymethod:2:method" VALUE="Delete item 2"> and so on. Incidentally, is the ':method' trick documented? - I can't find it in the DTML guide.

2 1

cgi_module_publish cookie prsing errors?
by tsarna＠endicor.com 02 Apr '99

02 Apr '99

All of my "real" sites are still running under Principia. Recently a number users of these sites have had their machines upgraded. Those now using the latest versions of IE and Netscape are unable to access the sites now unless they turn off cookies, or they get an error in cgi_module_publish to do with parsing cookies. (I'm still trying to get someone to send me the actual error text). Anyone out there using Principia still? Have you seen this? Anyone using Zope seen this?

2 2

Building Zope on BSDI
by John Eikenberry 01 Apr '99

01 Apr '99

Has anyone built Zope on a BSDI machine? BSDI doesn't support shared libraries, so everything has to be statically compiled into python. I just got it to build (python w_pcgi.py finished), but there doesn't seem to be a new python binary anywhere with everything compiled in. To get it to compile, I went through and deleted all the '*shared*' from the 'Setup' files. Any tips? As a side note, I was planning on using the binary porting kit to get it built, then contributing this back to the community. But the porting kit is still Zope-1.9. Is there any plans to update the porting kit. Thanks in advance for any help, --- John Eikenberry [jae(a)kavi.com - http://taos.kavi.com/~jae/] ______________________________________________________________ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin

3 3

RE: [Zope] Building Zope on BSDI
by Brian Lloyd 01 Apr '99

01 Apr '99

> > > Has anyone built Zope on a BSDI machine? BSDI doesn't > support shared > > > libraries, so everything has to be statically compiled > into python. > > > I just got it to build (python w_pcgi.py finished), but > there doesn't seem > > > to be a new python binary anywhere with everything > compiled in. To get it > > > to compile, I went through and deleted all the '*shared*' > from the 'Setup' > > > files. Any tips? <snip> > > So... any tips for compiling the Zope extensions as shared libs? I'll > probably keep working on the static python solution, as I'm actually > making progress on this, and I really have no idea where to start with > shared libs on BSDI (no good leads on dejanews, and egroups is > non-responsive as usual). > > Thanks, > > --- > > John Eikenberry Here are some things I've found in previous struggles to get Zope compiled on bsdish systems -- I'm no guru, though, and I've seen different things work on different bsdx flavors: o you usually need to add -rdynamic to LDSHARED in your Makefiles (this should be reported & worked into python's makefiles, IMHO) o I havent been able to get threads going on many bsd flavors - so you may not be able to pass --with-thread to configure o I find that extensions will all appear to blow up with unfound symbols (such as those you reported) - you need to run make -k and ignore the errors ;) o On some systems, I had to run make -k, ignore the errors, and rename the output .o files for the extensions to .so :( o I seem to remember having to use shlicc on .so files, but I dont recall the details... Hope this helps - please post a status rpt if you get it working, so that the gory details will at least be captured. This is the sort of thing that should be in an installation FAQ somewhere. Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

2 1