October 2000 - Zope-Dev

MailHost Improvements
by Kapil Thangavelu 09 Oct '00

09 Oct '00

There has been intermittent talk of improving mailhost's ability to scale. i just wanted to solicit some comments to some ideas for improving mail host performance. Stage I. Persistent Socket 1. make the smtp connection persistent 2. preface sending mail with a 'noop' operation to verify connection status 3. overide __setstate__ to open connection i'm not sure if this will yield any real world benefit but i like the style better than opening a new connection for every new message. Stage II. Transaction Aware 1. Store sent mail in a volatile 2. on transaction commit begin (tpc_begin), send all mail, if error abort transaction 3. reset volatile again i'm not sure of real world performance, but the design seems better and the added benefit that it will play nicely with the transaction machinery and not send unesc. emails. Stage III. Intelligent Q. aka the BulkMailHost 1. implement mailer thread / sole function to send mails from queue and intelligently manage a outgoing queue and deferred queue. 2. implement extensions to sendmail tag for immediate sending of mail which will wake/signal mailer thread after depositing into outgoing q. extension options are 3. mailer thread on a timer, so it will wake on either a sendmail tag with immeadiate extension or on timer expiration and send mail from queue, messages with error due to connection or placed in deferred queue. messages with undelivarable errors are either deleted or placed in a deleted queue. 4. all queues are viewable and manageable from the management interface. obviously this makes the sendmail tag async to the message being sent. i'm not sure if this something that really should be implemented in a ZODB default file storage due to the high write nature of the system or just dumped to the fs. again this seems questionable also because a proper mta should be operating on a store and send principle (qmail/postfix). comments? hmmm... looking through the source of the 2.2.2 mailhost i see a scheduledSend method, anyone know what this is from/for? Cheers Kapil

2 1

ZPublisher.Client
by Andrew Edmondson 09 Oct '00

09 Oct '00

I used to use Client.py quite a lot for calling zope objects through the web from python. However, now that I've upgraded to Zope 2.x it fails. (Zope 2.2 ZPublisher, connecting to Zope 2.1.2) Traceback (innermost last): File "/u/g/aedmondson/backups/pack_db.py", line 22, in ? pack() File "/u/g/aedmondson/backups/pack_db.py", line 19, in pack return(apply(Client.Function(place,username=user, password=pwd), (), kw)) File "/usr/local/ZOPE2.1.2/lib/python/ZPublisher/Client.py", line 221, in __call__ raise NotAvailable, RemoteException( bci.NotAvailable: (111, 'Connection refused') (File: http://localhost/Zope/fastcgi/Control_Panel/Database/manage_pack Line: days:int=0) None None for None (Both Zope 2.2 (in fact, the same python)) Traceback (innermost last): File "<stdin>", line 11, in ? File "<stdin>", line 8, in test File "/usr/local/Zope-2.2.0-linux2-x86/lib/python/ZPublisher/Client.py", line 221, in __call__ raise NotAvailable, RemoteException( bci.NotAvailable: argument 1: expected read-only character buffer, tuple found (File: http://localhost/idm Line: []) None None for None Is this a problem with ZPublisher, or me? Thanks, -Ed

1 0

Re: [Zope] Container Class questions
by Dieter Maurer 09 Oct '00

09 Oct '00

Robin Becker writes: > I would like to add properties in a property sheet, but cannot find a > neat way to see the properties on the base object and on the > propertySheet. > > So I would like my properties to show > id > title > > and the properties on my basic properties sheet. > > I can easily add properties directly to the object during the Thing_add > and Thing_addForm and these appear on the properties tab for added > objects. > > How do I get a tab for the property sheets? I am not sure, I understand precisely, what you want to reach. ZClass properties are managed on distinct property sheets. I do not know of a neat way to present (and change) properties from different property sheets (other than adapting the "manage_PropertiesForm" manually). To get a tab for a single property sheet (other than the default one), you define a "View" (in the ZClass) for it. I agree with you, that there should be a way to add properties to the "inherited" or "default" property sheet (or, more generally, any inherited property sheets, e.g. from inherited ZClasses). When I read the code, I had the impression that access to the default property sheet should be able via the property sheet name 'default'. Unfortunately, it did not work (Zope 2.2.2). Apparently, there is some missing link. Dieter

3 2

Re: [Zope-dev] Accessors for DataSkin attributes (was Re: [Zope-dev] Success!
by Steve Spicklemire 09 Oct '00

09 Oct '00

>>>>> "pje" == Phillip J Eby <pje(a)telecommunity.com> writes: pje> It is *not* undesirable to have ZClasses be subclasses of pje> your core logic base class. Just make sure they *also* pje> subclass DataSkin, or that you use the metaclass definition pje> stuff above. You've actually got a pretty decent approach pje> going there. Hmmm.. again, maybe I'm reading too much into the DropZone example, but I seem to recall there that subclassing was pretty much explicitly discouraged. Did I misinterpret that? ''' Notice that we do not subclass SkyDiver from a Customer class and a ResourceUser class. What we are doing is saying is that Customer is a role that a Party (person or organization) plays in an accounting system, and ResourceUser is a role that a Party plays in a resource scheduling system. SkyDiver, then should implement a Party interface, allowing it to be used as a Customer or ResourceUser. Thus, SkyDiver can be used by any framework that needs to collaborate with a Party object, although it may have a new role in which the party will be used. For example, if I later add a curriculum management system to cover my skydiver training courses, I will want SkyDiver to fill the Student role. ''' OK.. allow me to summarize my very latest thought. Subclassing is OK withing my own framework. It's OK to require users of my framework to create ZClasses that subclass from my core logic Python classes, and from DataSkin. If we need integration between frameworks, we can handle that in SkinScript to share attributes between Specialist, or anthing else that might be helpful in providing the needed information. Does that sound right? pje> One question, though. Why the derivation from Folder? Oh... this was a case where my object, in addition to 'simple' properties also needed to 'contain' other stuff (files, images and the like...) making it a subclass of folder just got me that ability for 'free'. I could also have used ObjectManager, but making it folder just reduces the amount of 'UI' effort needed for the management interface of the contained stuff. I could have just created a plain folder with the same 'id' as my DataSkin, and 'associated' they two, but it made some sort of sense to keep them all together. -steve

2 1

ZPatterns design questions
by John Eikenberry 09 Oct '00

09 Oct '00

First, some context... I'm working on a new data storage system for a related set of (primarily) Zope sites. The data will be kept in ZODB and mirrored out to a RDB (MySQL) to provide read-only access to some non-zope stuff. One other thing to note, all of this will be done via python code (no zclasses). Now say that I want to keep data about a company. I have a specialist, rack and dataskin already created. I currently can store data on the skin via AttributeProviders, but this was mainly done to get something working to mess around with. What I think I want is several SheetProviders. Two for each block of data (a block basically reflect the breakdown of tables in the MySQL DB). Why 2 for each block, one for the ZODB store and one for mirroring the data out to the RDB. So, the breakdown for the company would look like this: Company Rack - Company Information (name, url, etc). . SheetProvider (ZODB) - read/write . SheetProvider (SQL) - write only - Address Information (city, state, zip, etc) . SheetProvider (ZODB) - read/write . SheetProvider (SQL) - write only Does this sound reasonable? I thought about writing a mix-in class to add the SQL stuff to the SheetProvider, eliminating the need for 2 entries for each block of data. But I liked the idea of each being its own plugin, seemed cleaner. The specific question I have about this design is where does the _properties() attribute go? They need to be associated with their appropriate SheetProviders, so that seems the most likely place, but that would require a SheetProvider subclass for each data block which bothers me. It also just doesn't seem to fit in with the design pattern, but my understanding of it is still fairly limited. Next Topic... Adding to the above design, we add a second entity; People. I need to express relationships between the people and the companies. These relationships can be of various sorts; eg. technical contact, marketing contact, company admin, etc. My idea is to create another specialist/rack/dataskin to contain the information about these relationships and associated data (type of relationship, corresponding roles, references to the related entities, etc). I don't have any code for this aspect of the design yet, so I'm only fishing for general criticisms/thoughts at this point. Is there a better way to do this? BTW, there are going to be many more types of entities and relationships that these examples, so it needs to scale. It also needs to perform well, as the authentication mechanism will be fetching the roles off the relationships and, possibly, their related objects. Thanks in advance for any advice. -- 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

5 19

A good collaboration 'partner' ? Was: ZPatterns design questions
by Spicklemire, Jerry 08 Oct '00

08 Oct '00

Hi Steve, and fellow ZPatterns Wannabees, As to the sorts of things most of us need to keep track of that could tie into a simple "ToDo" List, so far we've seen suggestions for an Address Book and Deliverables. The first sounds kind of like a Contact List to me, or maybe an Ownership or Collaboration List. A way to keep track of other folks involved or concerned with each "ToDo" item. The second sounds like adding a Status Field to each "ToDo" item, and defining what it takes for each to be tagged as "Done". This might take the form of completed steps, finished output, or whatever, making up a sort of mini-workflow. In the a Normalization process of a tabular database each of these could be seen as child tables, since there could be more than one Contact or Deliverable for a "ToDo" item in the parent table. While we're on the subject of fleshing out a "ToDo" schema, consider a interfacing with a simple calendar, for task scheduling. This would enable assignment of target dates, and dependencies. For example, if task B must be done by the 37th of Penultember, the closer we get to the 37th, the "hotter" task B gets. Furthermore, if task A must be at least halfway complete before task B can be started, task A should heat up even sooner. This is basically the sort of thing a Project Management system does. A simple dependency model might be added in the form of a few "rules" based on comparing status, dependency, and target dates. "Hot" items could be highlighted for special attention, when a critical threshold is crossed. This may be too ambitious, or even counter productive. I realize the point is not to create the ultimate Personal Information Manager application, but to illustrate how ZPatterns aids integration across "unrelated" applications. Still, integrating an Address Book, Calendar, and ToDo list isn't all the far fetched, as each one could have been created as handy little stand alone utilities. On the other hand, knowing you're working on something that could actually turn out to be useful might assist in the motivation process! Later, Jerry S.

1 0

A good collaboration 'partner' ? Was: ZPatterns design questions,
by James Johnson 07 Oct '00

07 Oct '00

I'm thinking along the lines of an address book to collaborate with the todo list or maybe a short inventory list of items in stock or needing purchase. This way a person from the address book can an item from the inventory to do something from the list. Sounds like alot of work to me, but I think the beauty and magic of Zpatterns makes it easier for them to collaborate yet function as standalone applications. Get your Free E-mail at http://tacoma.zzn.com ____________________________________________________________ Get your own Web-Based E-mail Service at http://www.zzn.com

1 0

Re: [Zope-dev] ZPatterns design questions
by Steve Spicklemire 07 Oct '00

07 Oct '00

>>>>> "pje" == Phillip J Eby <pje(a)telecommunity.com> writes: >> - Propertysheets: You don't expressly say that Shared needs to >> be a 'Common Instance Property Sheet'. pje> Actually, if it's intended to be shared across all instances, pje> there seems to me to be little reason to have it in the pje> ZClass; you might as well define the properties as constants pje> using SkinScript. However, if you want to have defaults that pje> an application integrator will be able to override without pje> actually subclassing, then you want Shared to be a DataSkin pje> Property Sheet, so that they will have the option of pje> overriding your defaults with SkinScript or another attribute pje> provider. Yeah.. now that I think about it a little more clearly, it makes sense to define this in the Specialist itself. This way all the instances in a ToDoManager would share the same set of 'doers', but different ToDoManagers could keep their own custom set. >> - I'm trying to reconcile PJE's methodology of Domain Logic, >> Presentation Logic, Data Management Implementation Logic, and >> User Interface Implementation Logic. Can you (or Phillip) label >> each of the DTML methods as to which category they fall into? >> And state why, even if it seems obvious? pje> In the ZClass: pje> index_html - presentation, because it displays things the pje> object knows pje> editInstanceForm - presentation, because it is strictly pje> display pje> editInstance - primarily domain, but mixes some presentation pje> in. If instead of displaying an OK button, it just did a pje> redirect, I'd consider it a pure domain. Note, by the way, pje> that it's not wrong to mix the two, it's just usually more pje> reusable to keep presentation code out of domain methods if pje> you want to be able to call them from code or XML-RPC and pje> such. Good! This is the kind of feedback I need! So.... I can pass in a redirection URL so that the domain code can work in different environments easily. pje> In the Specialist (btw, stric: pje> index_html: UI implementation, because it implements a pje> non-object specific UI (i.e. "display all to-do's"). pje> newToDoForm: UI implementation, because it's a non-specific pje> object UI. pje> addNewToDo: DM implementation, polluted by a bit of UI. :) pje> It implements the data management aspect of creating a new pje> instance. It calls the Specialist's newItem() method, but it pje> could have directly called a newItem() method on one of the pje> Specialist's Racks, or done something else to create the pje> instance. pje> deleteInstances: DM implementation, again with a touch of UI. pje> It implements the data management aspect of creating a new pje> instance. Instead of doing manage_delete on each item, this pje> could have been implemented as an SQLMethod that did a DELETE pje> WHERE operation using the id's that were given (if the data pje> store was an SQL database, of course). OK.. I'll go back and try to 'clean out' the UI pollution to illustrate that separation better. >> - How does this product (simple though it is) exemplify the >> RIPP approach? pje> I'm not sure that you can say it *exemplifies* the RIPP pje> approach, although it certainly goes along with that pje> approach. My hesitation is mainly that it doesn't really pje> show any of RIPP's major benefits, which are associated with pje> framework re-use and integration. For that, you really need pje> to have more than one kind of object, with some kind of pje> collaboration taking place. Hmm.. can anyone thing of a good collaboration 'partner' for a simple ToDo list? If it's not too complex.. I'd be happy to add it. thanks, -steve P.S. my first alpha of EMarket based on ZPatterns is just about ready. I'm sure it's full of similar pollution. This would be a great place for a design review. ;-)

2 1

ZODB
by Roch'e Compaan 07 Oct '00

07 Oct '00

I am getting really funny problems with my Zope installation and I have no idea where to start looking. I for instance deleted a python product from the Products directory and when I start Zope the product is still listed in the Product list. I then packed the ZODB, cleared my Browser's cache, and refreshed the Product List but still the product is visible. I can however delete the python product (which is by the way not in my Products directory) from the Control Panel. Somewhere something is cached and I don't know where. It seems to cache errors as well and they stick. A reinstallation fixed this problem, but now it seems more fundamental. I've come accross this odd caching behaviour again after reinstall and can't reinstall every time this happens. I run Zope 2.2.2 behind Apache 1.3.9 and do virtualhosting with the ProxyPass directive. Please help!! Roché

3 3

Refresh and debugging product creation issues.....
by Steve Spicklemire 07 Oct '00

07 Oct '00

Debugging products is a pain... restarting Zope all the time is a Pain.... THANK GOD for Shane Hathaway. ;-) I am delighted to report general success with the Refresh product! My only problem is while debugging the process of creating new EMarket instances, I find that every time I run 'Refresh' I get a new "EMarket" in the 'Available Objects' popup. A quick test of other Products shows the same behavior. Soo... I snooped through the product creation code and found that Products.meta_types was being unconditionally appended to every time context.registerClass was called.... so I changed my initialize to this: def initialize(context): import Products context.registerClass( EMarket.EMarket, permission='Add EMarkets', constructors=(EMarket.addEMarketForm, EMarket.addEMarket), icon='emarket.gif', ) found_count = 0 new_products_meta_types = [] for index in range(len(Products.meta_types)): if Products.meta_types[index]['name'] == EMarket.EMarket.meta_type: found_count = found_count + 1 if found_count == 1: new_products_meta_types.append( Products.meta_types[index] ) else: new_products_meta_types.append( Products.meta_types[index] ) Products.meta_types = tuple( new_products_meta_types) In other words... only include the original version of EMarket.EMarket.meta_type in the Product.meta_types tuple... if there are others... leave them out. ...and that seems to have solved the problem.... Does this seem like an OK idea? thanks, -steve

1 0