December 1999 - Zope-Dev

RE: [Zope-dev] Re: [Zope] Zope direction and 2.2 roadmap...
by Brian Lloyd 09 Dec '99

09 Dec '99

> >Now that Zope 2.1.0 is out the door, we at DC want to let > >the community know our direction and the "roadmap" leading > >to 2.2. In a nutshell, our direction and focus will be on > >usability. Making it easier to get things done with Zope has > >been a recurring theme on the lists lately, and we will be > >working to make progress on this front. For 2.2, here is the > >short list of we will be working on: > > Any plans to include the new "local" and "set" tags I > submitted for perusal > a month or two ago? Thanks. The subject of DTML is a volatile one at the moment, as I'm sure you've seen from the list :) One of the big goals for 2.2 is to see how effective the integration of Python Methods is at reducing the necessity for complexity in DTML. The hope is that PMs will help reduce the need to introduce ever more constructs into DTML, so I plan to wait a while so that we can evaluate the results of the PM effort before adding anything more to the DTML core. I will definitely be interested in feedback from Zopistas on the effect of PMs on the sort of problems that tags like "local" and "set" propose to solve. Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

3 2

RE: [Zope-dev] Zope woes continue
by Tres Seaver 09 Dec '99

09 Dec '99

Michel Pelletier <michel(a)digicool.com> wrote: > > > -----Original Message----- > > From: Stuart 'Zen' Bishop [mailto:zen@cs.rmit.edu.au] > > Sent: Wednesday, December 08, 1999 8:58 PM > > To: Michel Pelletier > > Cc: zope-dev(a)zope.org > > Subject: RE: [Zope] Zope woes continue - server going down regularly. > > (pos sible solution) > > > > > > On Wed, 8 Dec 1999, Michel Pelletier wrote: > > > > > This is because the connection gets opened, but never > > closed. Zope 2.x > > > is hardwired to have only 7 available database connections. We'll > > > probably add a knob in 2.2 that lets you configure the number of db > > > connections. In either case, the problem is not the hardwiring, the > > > problem is that your code has a bug in it, because you do > > not free the > > > resource you are consuming. Do an: > > > > > > x.close() > > > > > > at the end of your method and you won't run out of connections. > > > > Erm.... shouldn't ZApplicationWrapper have a __del__ method > > to do this, > > just in case? It isn't in there... > > I messed up, it's x._p_jar to get the connection, but I see your point. > You wouldn't want to do this, because other objects other than the root > object may be using it. Who has access to the newly-created connection, beyond the ZApplicationWrapper object which is going to go out of scope and be destroyed? > > > Otherwise, you would really need > > > > try: > > x = Zope.app() > > # ... stuff > > return "Hello World!" > > finally: > > x.close() > > Yes this actually works best. > > -Michel I don't buy it: if Zope.app() constructs and returns an object, whose constructor has a side effect of opening a new ZODB connection, then that object OWNS that connection and should clean it up in its destructor. Using try..finally to handle a _hidden_ side effect is convoluted -- this is why refcounts were invented. Tres. -- ========================================================= Tres Seaver tseaver(a)palladion.com 713-523-6582 Palladion Software http://www.palladion.com

1 0

Re: [Zope-dev] I have a dream!
by Simon Michael 09 Dec '99

09 Dec '99

I came across this yesterday at cosource.com, and I think it's worth checking out. It's an all-XML, open source web-app platform. http://www.risource.org Excerpts from the faq: In the PIA framework, each application consists of two parts: 1.A collection of task-specific XML pages which contain active-processing tags (<if>, <include>, <repeat>,, etc); These look very much like HTML pages. 2.A core software layer (including a dynamic XML processor) that is shared by all applications Broadly speaking, the PIA does three kinds of things: Act as a web server, reading and processing active-XML documents and serving up HTML for view. Act as a browser proxy, intercepting incoming HTML pages and modifying them (e.g. deleting ads or filling-in forms) and showing you the modified page. Act as a document processor, processing active-XML documents into HTML or XML files. In each case, the PIA processes a markup document to produce another markup document, based on the particular active tags ("tagset") associated with the source document.

2 1

RE: [Zope-dev] Re: [Zope] Multi tier partitioning meaningful in s ome Zope apps ?
by Ken Manheimer 09 Dec '99

09 Dec '99

Mr Greg Ward wrote: > * involuntary use: all my user interface code (DTML methods and > documents) goes into this big mysterious object database. > I have nothing against object databases, and I'm glad to > see a free one for Python. But dammit, to me this stuff isn't > data, it's *CODE* -- and code is far too precious to entrust > to a database. I want it in a filesystem with full CVS control > over it. I want to be able to back it up with tar or afio, > one file at a time (or rather, restore it one file at a time, > if need be). I don't want my code locked up in this big > box of data. I don't happen to mind the db holding my code, but like you, i also really really want the friendly familiar comforts of holding the code in the filesystem - CVS susceptibility, opportunity to grep to my hearts delight, why, even editing with emacs!! FTP access (which dtml in ZClasses still doesn't have - partly my fault, i had the prerogative but never found the time to do that) doesn't satisfy me, because the code is still either in the ZODB or in the filesystem, and i want the benefits of both. The upshot is that _my_ preference would be to have something like the provision for external methods, where stashed copies of the code is kept in the ZODB, synchronized (automatically, when zope's running in debug mode) with copies in the filesystem. This perspective, possibly shortsighted, is based on the procedure i (bravely admit i) use to edit ZClass dtml code, in the few projects where i do so. I maintain all my dtml in the filesystem, checked into cvs in the filesystem, edited with emacs, and (wheeze) i cut and paste using X and a handy emacs macro, into the pAthetic browser text widget. I'd be ever so happy if Zope would cut out that last step, and do the sync for me. (I would prefer that the autosynchronization were switchable in an acquired way, so i could set installations on a per-product basis, switching my production-sensitive products to a safer manual-sync setting, and my under-development ones to the sleeker autosync...) > Enough ranting for now. Guess I should do as AMK recommended and join > zope-dev... sigh... I'll *never* get any work done now... (I can't keep up with the traffic.) Ken Manheimer klm(a)digicool.com

1 0

ZDiscussions cataloging
by Ethan Fremen 09 Dec '99

09 Dec '99

Mike, I'm using ZDiscussions and am quite happy with it. A question and a problem: when does the Zdiscussion catalog Items or are Items all CatalogAware? I've noticed a delay in searching... For some reason, when I try to search for a reply to a top level item (by title) it does not appear. I've checked the title and also reindexed. What could be going on? -- Ethan "mindlace" Fremen you cannot abdicate responsibility for your ideology.

2 2

RE: [Zope-dev] Shutting down ZServer
by Amos Latteier 09 Dec '99

09 Dec '99

> We're experimenting with Zope 2.1 and FastCGI; this marks the first > time I've seriously used ZServer, and I have a possibly silly > question. An odd behaviour I've noticed is that 'Shutdown' on the > Control Panel isn't shutting down Zope; while the usual SystemExit > traceback is printed, the Zope process hangs around, preventing > FastCGI from starting a new Zope server on the next request. > > Before I spend some time tracking this down, I want to be sure that > this isn't expected behaviour; should ZServer be shut down > differently, by some means other than the control panel? Yes 'shutdown' from the Control Panel is supposed to cause Zope to exit. Let's see, after you shutdown will Zope accept any more web connection? Does 'restart' from the Control Panel work? Does shutdown via HTTP (as opposed to FastCGI) work? What web server, fastcgi module, and platform are you using? It sounds to me like a problem with the FastCGI server, though if you can't shutdown Zope with plain HTTP then there is a deeper problem. Let me know and I'll look into it. Also just to clarify FastCGI operation -- normally once you shutdown Zope your web server won't be able to restart Zope, even though this is how many FastCGI applications work. You should use Zope's 'restart' capability if you just want to restart it. Good luck! -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com

1 0

Re: [Zope] Multi tier partitioning meaningful in some Zope apps ?
by Patrick Phalen 09 Dec '99

09 Dec '99

[Moved to ZOPE-DEV for hopefully further discussion] [Greg Ward, on Thu, 09 Dec 1999] :: My preference -- after only a few weeks with Zope, mind you -- is to put :: as little logic as possible in DTML. Restrict it to display/user :: interface logic; anything more than that, and you'll be in :: teeth-gnashing-land pretty quickly. It's not a general programming :: language; that should be obvious from the fact that it doesn't have :: variable assignment (except in the limited "let" sense). :: :: Business logic should be coded in Python, and interfaced via External :: Methods. (I guess you could use these newfangled Python Method :: thingies, but I want *more* in the filesystem and *less* in ZODB, thank- :: you-very-much.) Note: *interfaced* via External Methods; I like my :: External Methods to be fairly short little things that deal with stuff :: like translating Web/HTTP/Zope pecularities to the more general world :: addressed by my back-end Python classes. :: :: > Data Access -> ZSQL-methods -> Data API (JDBC-like) :: :: Hmmm. It's entirely possible that data access could/should be managed :: by just making all those back-end Python classes inherit from the ZODB :: Persistent class -- bang! no more SQL to worry about. That's an awfully :: big leap of faith to take, though... This is worth further discussion, expansion, IMO. I'm curious if you (Greg) are finding that your External Methods that "deal with stuff like translating Web/HTTP/Zope peculiarities" are shaping up to be reusable code. I'd also like to see an example or two to see how you're approaching this, if possible. I wonder if we could have a few base classes which would take care of the majority of these situations. I'd certainly welcome further thoughts/comments from others on this approach, particularly pros/cons on the "big leap of faith" part in the last paragraph.

3 3

RE: [Zope-dev] I have a dream!
by Phillip J. Eby 09 Dec '99

09 Dec '99

At 10:32 AM 12/9/99 -0500, Michel Pelletier wrote: > >While were on the subject, I have a dream too, people not sending HTML >encoded mail to the list. ;) > Your dream is perhaps much nearer to realization than a JZope implementation. :) Ty recently wrote a Python de-HTML/de-attachmentizer which we use to sanitize incoming e-mail to IDS. I am officially authorizing the donation of the current version of that code for y'all to use, especially if you'll turn it into a Mailman patch that can then benefit other Mailman users. The de-attachmentizer recursively converts all parts of a MIME message to text, correctly handling all the various multipart/* variants. It throws away winmail.dat and other common MS yuckies, as well as leaving behind text notations describing the binary attachments that were removed. If it finds an HTML part that has no plain text alternative, as a last resort it uses Python's HTML-to-text functions to crudely format it. No HTML which is identified as such in any mail header will survive intact, and nothing which is not text will survive at all. :)

2 1

Re: [Zope] Zope direction and 2.2 roadmap...
by Phillip J. Eby 09 Dec '99

09 Dec '99

At 02:55 PM 12/8/99 -0500, Brian Lloyd wrote: > >Now that Zope 2.1.0 is out the door, we at DC want to let >the community know our direction and the "roadmap" leading >to 2.2. In a nutshell, our direction and focus will be on >usability. Making it easier to get things done with Zope has >been a recurring theme on the lists lately, and we will be >working to make progress on this front. For 2.2, here is the >short list of we will be working on: Any plans to include the new "local" and "set" tags I submitted for perusal a month or two ago? Thanks.

1 0

A simple feature suggestion
by Jim Cain 09 Dec '99

09 Dec '99

When you click on the Rename button for an object and go to the rename form, it would be nice if the text field was already populated with the old name. Jim

3 5