October 2000 - Zope-Dev

RE: [Zope-dev] More almost __call__ ;-)
by Toby Dickenson 13 Oct '00

13 Oct '00

> Is it *really* the case that you often want to method to be > called directly > via the Web *and* and from DTML? This doesn't seem right to me. Im suprised that you are suprised. Consider a method called 'summary' that returns a plain-text summary of an object. Thats useful to call from DTML (maybe assembling a summary of several objects), via xmlrpc, and directly from ZPublisher (by browsing to the url of the method). Maybe this 'summary' method lets you pass some parameters to control the level of detail of this summary. These requirements are probably best satisfied using a plain python method, which uses plain python parameters. So why use the dtml namespace at? The only good reason is if the method was *previously* implemented in DTML (it seemed a good idea at the time) and you want to replace it with python without having to change all the dtml that uses it.

2 1

RE: [Zope-dev] More almost __call__ ;-)
by Toby Dickenson 13 Oct '00

13 Oct '00

> That looks like it'll do the trick... I wonder if there's any way you > can role it up into a Product so that I don't need to have > FunctionTemplate.py in each folder of a product that needs to use it? Im working on a set of tools to aid my transition to a dtml-free Zope. Eventually I will package them all as a whole.

2 1

Compile zope with kgcc instead of gcc
by Magnus Heino (Rivermen) 13 Oct '00

13 Oct '00

How do I compile Zope with kgcc instead of gcc? (Yes, I need to do this since I am using RH7.0 where LONG_BIT is defined the wrong value). /Magnus

1 0

Xron fragility
by Steve Alexander 13 Oct '00

13 Oct '00

The Xron product seems rather "fragile" in use. That is, if things go wrong when an Xron DTML Method is triggered, that method doesn't get rescheduled. An example of this is that my intranet DNS server needed to be rebooted. Xron couldn't look up the appropriate domain name, and stopped working. ------ 2000-10-11T08:16:34 PROBLEM(100) Products.Xron.Loggerr Trigger event: http://my.development.server:4080/my_xron_method Trigger time: 2000/10/11 09:14:00 GMT+1 Failed to trigger event. Type=bci.NotAvailable Val=host not found (File: http://my.development.server/my_xron_method/trigger Line: []) None None for None ------ 2000-10-11T08:19:04 PROBLEM(100) Products.Xron.Loggerr Failed to disarm event Also, if something bad happens in the Dispatcher thread, the thread dies. Before I leap in and start patching Xron, I'd like to have a discussion about how Xron should handle problems. My first thought is that on errors in the dispatcher thread, Xron should enter an "error state" where it probes every so often to see whether it can resume normal operation. The length of time between probes could increase with each probe, to give good performance with transient problems whilst preventing Xron from choking resources. -- Steve Alexander Software Enigneer Cat-Box limited http://www.cat-box.net

5 15

Re: SessionManager, BerkeleyDB, and license compatability
by Stefane Fermigier 13 Oct '00

13 Oct '00

On Thu, Oct 12, 2000 at 12:00:07PM -0700, zope-dev-admin(a)zope.org wrote: > From: Toby Dickenson <mbel44(a)dial.pipex.net> > To: zope-dev(a)zope.org, chrism(a)digicool.com > Cc: James Wilson <jwilson(a)geminidataloggers.com> > Subject: [Zope-dev] SessionManager, BerkeleyDB, and license compatability > Date: Thu, 12 Oct 2000 15:04:28 +0100 > Reply-To: tdickenson(a)geminidataloggers.com > > I understand from the SessionTracking wiki that this product may use > BerkeleyDB > > http://www.zope.org/Wikis/DevSite/Projects/CoreSessionTracking/CurrentStatus > > The BerkeleyDB license at http://www.sleepycat.com/licensing.html > indicates that it may only be distributed free of charge with software > that is 'freely available and redistributable by others'. > > We are currently using Zope to develop an application that does not > fall into this category. It would be a serious problem for us if > Zope's core had a dependency on code with this type of license. If I remember correctly some information I got on the Python newsgroups long time ago, the Sleepycat people only care that Python, which is linked to BerkeleyDB, is free. The free/commercial status of the application you will write in Python (including Zope and third party products) is not relevant to them. S. -- Stéfane Fermigier, Tel: 06 63 04 12 77 (mobile). <www.portalux.com>: le portail Linux / logiciel libre. "Amazon: we patent the dot in .com"

1 0

Best practices for Zope development, staging, and production
by Bjorn Stabell 13 Oct '00

13 Oct '00

Hi there, We're betting our business on Zope, and we're in the process of setting up a good Zope development and hosting environment. We're running into some problems, however, that we'd like the list's feedback on. What is best practice, etc... It still seems awfully backwards the way we've got it figured out. Situation We're using Zope and PTK (newest releases via CVS) as a base. On top of this we will build our own extensions of the PTK, and on top of this again will be the portal instances for each client... Yes, we build websites for clients. We have a development server and a production server. We have a ZEO setup, but we're not using it at this time for stability reasons. If we were to draw a layered model, it would be like this: client layer: client-website-1 client-website-2 etc... our reusable layer: our-own-DemoPortal python-product-inherited-from-PTKDemo DC-PTK layer: PTKDemo (and implicitly PTKBase) DC-Zope layer: Zope ExoPortal is our own DemoPortal, a "copy" of DemoPortal with our own additions and changes. It inherits from ExoToolkit, not PTKDemo. ExoToolkit is our own python product that inherits from PTKDemo. This should allow us to build a layer above DC's PTK. Things are complicated by having to deal with sites in different stages of their lifecycle, different servers (dev and prod), several developers, products in both the ZODB and on the filesystem, etc. In addition, changes will happen at all layers, by different parties. The Problem How do we develop, and keep all the client websites working all the time, while maximizing reuse; i.e., having them benefit from upgrades done by different parties (in this case us and DC) at different levels? A walkthrough of the layers Client websites are instances of the ExoPortal.Portal class, and they have a set of interface DTML methods copied from the interface directory. We want the client websites to take advantage of upgrades in the ExoPortal.Portal class, and we want to have a production version running, while at the same time working on a development version, which we will stage/test, and later replace with the production version. We can use Zope versions for development versions, and merge them into the production version, but we'd rather do big development on a local development server and merge the changes into the production server when they've been tested. The problem then is: how do we do that? We only want to update presentation and logic objects, not content objects, and the way Zope is now it's hard to see how to cleanly separate content from presentation and logic all the time. ExoPortal poses its own problems. It is basically similar to DemoPortal, and we see now other way to keep it synchronized with DemoPortal than to manual inspect new versions of DemoPortal and incorporate the changes into ExoPortal. Several servers doesn't pose a big problem as the copies of ExoPortal should be the same; there is no "content" to worry about, only logic and presentation. Of course, changes to the template interface DTML methods will not automatically be reflected in the client websites, but that's expected and acceptable; there is no other way. ExoPortal has to be kept in sync with the ExoToolkit the same way DemoPortal is kept in sync with PTKDemo. ExoToolkit inherits from PTKDemo. Intuitively it seems better to have it inherit from PTKBase, but it turns out that way we'll miss out on a lot of the functionality of the PTK that's put in the PTKDemo. ExoToolkit is file system based, of course, and shouldn't have any user interface files (unlike PTKDemo that has DTML files for all the portal content classes on the filesystem). When PTKDemo is updated, ExoToolkit might break, so we have to take care to fix it every time. PTKDemo+PTKBase and DemoPortal constitutes the PTK layer, controlled by DC. We use CVS to keep them up-to-date. We reuse PTKDemo through inheritance (automatically), but DemoPortal can't be reused that way so we have to do manual inspection of changes in the new DemoPortal for each update, and incorporate the changes into ExoPortal. Separating presentation, logic and content Logic and presentation are updated by us (programmers and graphic designers), but content is managed by the client. We need to be able to develop presentation and logic on a development server, move it over to the production server, without affecting the content already on the production server. Currently I don't see an easy way to separate presentation, logic and content without giving up working in Zope objects and putting all the content in a SQL database. Does anyone have experience with this? How is Zope.org updated? I'm sorry if my questions are stupid, but I'm sure many people are having the same problems. I have read most of Zope.org without finding obvious answers. I think we need to figure out what are the "best practices". Bye, -- Bjorn Stabell <bjorn(a)exoweb.net> Exoweb - One-to-one web solutions w http://www.exoweb.net/ t +86 13701174004

1 0

A couple of ZPatterns questions
by Itai Tavor 13 Oct '00

13 Oct '00

Hi, 1. I want to set some object attributes every time the object is changed (for example, to store the name of the user making the change). I looked at using a Generic Trigger or a SkinScript but I can't figure how to do it with either one. With a Trigger, I guess I need to set "Set Sttrs" to all the object attributes except the ones I intend to set (otherwise, would setting an attribute in the Trigger cause the Trigger to be called again?) and then call a method to set the attributes - but how do I set the attributes? Do I have to call changeProperties for the object or can I make the change directly on the DataSkin? With SkinScript, I can't figure out the STORE and USING syntax... also, if I use WHEN OBJECT CHANGED to change the object, would I get infinite recursion? Can I evaluate REQUEST['AUTHENTICATED_USER'] in the SkinScript or do I need to call a method for that? 2. I want to store a list of products, and give each one an arbitrary number of photos. I can use a Product ZClass, subclassed from ObjectManager and store Image objects inside it. But what will happen to these objects if I use this ZClass in a Rack? And how would I handle storing the objects in SQL tables - I will need to somehow turn each Image object into a table entry, and the same Generic Attribute Provider will have to work with 2 SQL tables. Is there a nice way of doing this? Or should I store the photos in a separate ZClass and use it in another Rack in the Products Specialist? Actually, I can't put an Image object on a DataSkin, right? So however I store it, it's going to have to be a my own custom Image object subclassed from DataSkin... TIA, Itai -- Itai Tavor "Je sautille, donc je suis." C3Works itai(a)c3works.com - Kermit the Frog "If you haven't got your health, you haven't got anything"

2 1

Observer Interface
by Itamar Shtull-Trauring 12 Oct '00

12 Oct '00

In order to make Shane's Symlink product (soft links to objects based on path) really usable, some sort of Observer interface is necessary. I know there was some discussion of implementing this in the Interfaces wiki and in zope-ptk. Did anything ever come out of this? Or was it never implemented? -- Itamar S.T. itamar(a)maxnm.com Fingerprint = D365 7BE8 B81E 2B18 6534 025E D0E7 92DB E441 411C

3 2

Re: [Zope-dev] Inheritable properties(sheets)? Anyone? Anyone? Bueller?
by Dieter Maurer 12 Oct '00

12 Oct '00

Alexander Schonfeld writes: > I want to inherit the properties of one zclass in another zclass, but > it seems to cause some namespace clashing... shouldn't this be possible? > Working with the instance of the class is fine, but inter-zclass > inheritance (acquisition?) would be nice... I think, I tried this once: You do inherit the property sheets of the ZClass derived from. Unfortunately, you will not see them via the property sheets tab and you can not extend them or provide different default values. You can use the inherited property sheets in the ZClass instances, though. I addressed this in a post "Abstract ZClasses", but apparently few people are interested in the question. There have been no responses. Dieter

1 0

Thanks for the comments
by Michel Pelletier 12 Oct '00

12 Oct '00

Just thought we'd mention that we have gotten lots of great comments on the Zope book so far, especially in the last week or so. You're all helping make it a better book and ensuring Zope's future. if you've felt in the past that you may not be technically proficient enough to contribute to the technology of Zope, you can certainly contribute to the documentation by catching our mistakes and making good observations and asking good questions. It is really, really helping. Keep it up, cuz we're not done yet! Thanks, Michel and Amos

1 0