March 2001 - Zope-Dev

INSTANCE_HOME vs. SOFTWARE_HOME
by Morten W. Petersen 19 Mar '01

19 Mar '01

Hi guys, some people have asked me to use INSTANCE_HOME instead of SOFTWARE_HOME, which breaks their products on debian distros. Now, I'm not sure that won't break other systems if I change it; anyone care to share? Thanks, Morten

2 1

Product Tutorial
by Magnus Heino (Rivermen) 19 Mar '01

19 Mar '01

Hi. Is http://www.zope.org/Members/hathawsh/PythonProductTutorial/index_html?pp=1 still valid, or have things changed since it was written? /Magnus

1 0

Re: [Zope-dev] Organizing modules in a python product
by Dieter Maurer 19 Mar '01

19 Mar '01

Itai Tavor writes: > ... abbreviated references to sibling subproducts ... > Is there any way to set this up so imports like 'import Utils' and > 'import Module2' would work in Module1? As a bonus, can I also get > __init__.py files in each module directory to be executed? You can manipulate (extend) "sys.path" in your (top level) "__init__.py" file. Python starts its package/module lookup from the elements in "sys.path". However, I doubt very much, that you should do this! You will lose the namespace isolation provided by packages. Dieter

2 1

iso_week for Zope's DateTime
by Steve Alexander 18 Mar '01

18 Mar '01

The Collector doesn't seem to be working at the moment, so I'm posting this here. I've written a small test for my iso_week function. You can download it, plus some test data, plus the script to create the test data here: http://www.cat-box.net/steve/zope_iso_week.tar (700k) You'll need to install mxDateTime if you want to make your own test data. You'll need bzip2 if you want to use the supplied test data. The function passes the test for all dates from 1600-01-01 to 2585-08-23. I've submitted it (with the date argument renamed self) to the Collector as a feature patch to DateTime.py. if you want to keep the standard DateTime.py, you can use it as PythonScript in Zope easily enough. ---- def iso_week(date): doy=date.dayOfYear() dow=(date.dow()-1)%7 y=date.year() thurs_this_week=doy+(3-dow) is_leap=y%4==0 and (y%100!=0 or y%400==0) if thurs_this_week>(is_leap and 366 or 365): week=1 if dow<8: y=y+1 else: mon_this_week=doy-dow day_year_begins=(dow-doy+1)%7 day_of_4_jan=(day_year_begins+3)%7 monday_of_first_week=4-day_of_4_jan week=(mon_this_week-monday_of_first_week)/7+1 if week==0: y=y-1 is_last_leap=y%4==0 and (y%100!=0 or y%400==0) if day_year_begins==4 or (day_year_begins==5 and is_last_leap): week=53 else: week=52 return y,week,dow+1 ---- -- Steve Alexander Software Engineer Cat-Box limited

1 0

New Zcatalog bug on b2?
by J�lio Dinis Silva 17 Mar '01

17 Mar '01

When passing in the REQUEST the var sort_on into the searchREsults method I get this error: Zope Errorr Zope has encountered an error while publishing this resource. Error Type: TypeError Error Value: len() of unsized object With this traceback: Traceback (innermost last): File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/Publish.py, line 187, in publish File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: Traversable) File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: executeSearch) File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: executeSearch) File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/OFS/DTMLMethod.py, line 189, in __call__ (Object: executeSearch) File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/DocumentTemplate/DT_String.py, line 538, in __call__ (Object: executeSearch) File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/DocumentTemplate/DT_Let.py, line 146, in render (Object: Results="Catalog(REQUEST=REQUEST)") File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/DocumentTemplate/DT_Util.py, line 334, in eval (Object: Catalog(REQUEST=REQUEST)) (Info: REQUEST) File <string>, line 0, in ? File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/Products/ZCatalog/ZCatalog.py, line 530, in searchResults (Object: Traversable) File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/Products/ZCatalog/Catalog.py, line 654, in searchResults File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/Products/ZCatalog/Catalog.py, line 591, in _indexedSearch TypeError: (see above) _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

3 2

Re: [Zope-dev] Designing ZPatterns/Python-product-based, reusable applications - take 2
by Itai Tavor 17 Mar '01

17 Mar '01

Phillip J. Eby wrote: >At 10:24 AM 3/11/01 +1100, Itai Tavor wrote: >> >>Then I need Specialists to manage collections of PD classes. I think >>that these would also benefit from being product-based, so I subclass >>Specialist to create a manager for each role in the application. Now, >>since an existing application might be expanded, the Specialists all >>need factory methods and will all show up in Zope's Add New Object >>menu. > >Or you may want to just create one factory method that creates an entire >family of related Specialists. Specialists do support TTW overriding of >their methods, if you set up the methods properly in your Python code. (I >forget how this works, though, you'll probably need to check the source code.) The reason I think I need factory methods for all Specialists is that it would enable adding features to an existing site - so it would support multiphase development. About TTW overriding of Specialist methods - didn't even think to look for such an option. I'll check the code. It could be very useful. > >- Many of the classes will also have web user UI, and since this has >>to be designed to fit the design of the web site in which the >>application is used, the UI methods will have to be located where >>designers can modify them - in the ZODB. For the Specialists, I can >>install a default set of UI methods when an instance of the >>Specialist is installed. But where do I store PD class UI methods? >>EMarket's solution is to store them in the Specialist, but this not >>only breaks O-O rules, it can also be very ugly. Say I have a >>Specialist managing 3 PD classes. Instead of an index_html method for >>each class, I'll need class1index_html, class2index_html, >>class3index_html in the Specialist. And each class would have to >>define: >> >> def index_html(self, REQUEST, RESPONSE, **kw): >> return self.class1index_html(REQUEST, RESPONSE, kw) >> >>This is unacceptably ugly. But the only other thing I can think of >>doing is creating a ZClass for each PD class and store the UI methods >>there. But that's also pretty unacceptable. Is there a better >>solution? > >Yes. Use "class_default_for_X" methods. (e.g. "def >class_default_for_index_html"). This will make them capable of being >overridden with a Class Extender in the Rack or Specialist. Class Extenders! Wow! I mean, Wow! I mean, this is great! Let me catch my breath... I got to learn to look under my nose more often. I just assumed that everything in the DataPlugins Add menu (other than Link to Parent Plugin) was made redundant by the use of SkinScripts. Just got to figure out the best way to use them... with class_default_for_X there won't be any ZODB-accessible default code to develop on, so for UI methods, creating the Class Extender along with the Rack, and filling it with default DTML methods might be a better idea. > >Next, I need object connections - these are created using >>SkinScripts. And as far as I can tell, I can't manage SkinScript in >>the product - they have to be in the ZODB. Which is ok in O-O land as >>they're not strictly part of the PD classes, but this means that PD >>classes don't actually work at all until someone comes and fills in >>the SkinScripts - so the class actually misses a lot of the code it >>requires to function. Also, it means SkinScript code can't be reused > >>with the rest of the application's components (except by cutting and >>pasting code pieces from an existing application). > >Your factory code can set this up, although I admit it's ugly. But when I run the factory code the SkinScripts don't exist yet... I create my DataSkins and install my Specialists and Racks first, then develop the SkinScript required by them... so the Python product never contains all the application code... unless I copy the SkinScripts back into the product. The problem here is that I don't write a general-purpose app that will later be customized into a working project - I write a custom app for a specific project, which I will later want to reuse. So when I finish development of the first app, parts of it are in the ZODB. At this point, copying them back into the product makes sense for the purpose of instantiating new copies of the product, but not for that app itself, because maintenance/bug fixes will still be done on the ZODB copies. > >Finally, I need to wrap the whole thing up as an application. So I > >create a Folderish class which installs instances of all Specialists, > >and add application-wide utility methods. Or do I simply place all > >Specialists in a Folder? > >Placing them in a folder would be fine. Actually, it would suffice simply >to install a meta type which creates all the Specialists in the selected >folder. Note that Zope does not require that a meta type correspond to >some physical class, or that an add operation result in a single object >being added to a container; you can add as many objects as you want in the >same operation. Never thought about doing things that way... interesting. > >Now, about reuse. O-O reuse, as far as I understand it, takes place >>at the class level. So how do I start a new application? Do I >>subclass its main container class and and my own init method that >>adds any added or subclassed Specialists I use? Or do I create my own >>application class and import PD classes from the old application? Do >>I copy the old classes into my new product, or do I import them from >>the old product, which then would require that the old product is >>kept on the server, even if the application that product defines >>isn't used on this server? > >If I understand you correctly, then you'd just instantiate another instance >of the application metatype, and then customize whatever needed to be >customized. I want every application I build to be based on its own object model. I can't stick to that if I instantiate an existing application, because that would bring in the entire object model of that application. I need to put together a collection of classes according to the object model, and some (often most) of these classes can come from the existing application. So my main problem here is how to get at these classes. Keeping a copy of the existing app to import classes from doesn't seem like a good idea... maybe I should get individual classes out of the CVS of the original application into the new product? But then what's to stop a programmer from going into these classes and changing them directly instead of subclassing them? > >And, as mentioned above, how do I reuse SkinScripts, Rack methods and >>SQL methods? Copy and paste? It seems funny that if I create a new >>instance of the product, I don't get a new copy of a working >>application... > >If your factory methods set this stuff up, then you're okay. So after you finished developing the ZODB-based parts of an application, you copy them into the product so it can install them the next time it's instantiated? > >On the other hand, considering that ZPatterns is now being superceded >>before it even had a chance to mature, maybe nobody cares to hear >>about it anymore :-( But more on that in a separate post. > >IMHO, ZPatterns is actually pretty mature - in terms of its code. By that >I mean, it has gone about as far in capabilities as its internal >architecture will allow. There are many minor improvements that could be >made, but they would be costly compared to their benefit. I would rather >invest the effort in something that will produce a greater gain for me and >the rest of the community. TransWarp will be much better for >filesystem-based, Python products than ZPatterns, which is almost 100% >through-the-web focused. Would you say then that it would be a better idea to keep ZPatterns development in the ZODB? Or is it worth the extra trouble to use Python products, even if ZPatterns is not designed to make that particularly easy? >he key phrase, though, is "will be". Right now, ZPatterns is the premier >system for doing "virtual objects" in Zope, and will continue to be for >some time. If Ty or I had to start on a new app today that needed the >things ZPatterns does, we would definitely use it. But we would also >probably take the time to prepare a good UML model for the app, so that we >could more easily port to TransWarp when it gets closer to being finished. This brings up another thing that bothers me: When I started learning object models and ZPatterns everyone advocated using Coad notation. Now Peter Coad himself is using UML and you're building TransWarp around UML. Is this a conspiracy to confuse me? Itai -- -- Itai Tavor -- "Je sautille, donc je suis." -- itai(a)optusnet.com.au -- - Kermit the Frog -- -- -- -- "If you haven't got your health, you haven't got anything" --

2 1

Playing with DateTime
by spinwing＠inwind.it 17 Mar '01

17 Mar '01

Hello I am playing around with the DateTime module in order to adapt it to other formats than the American one. However, I would like not to start a work that someone is already doing or that is already done. I have found a little patch that solves temporarily the problem, but I would like to do something more definitive. However, I need to be careful due to the large use that is done internally by Zope. To whom can I get in touch regarding this issue? Best regards Stefano Vedovelli

6 6

Re: [Zope-dev] (no subject)
by Gregor Heine 16 Mar '01

16 Mar '01

Hi Menno, what you get from the form is a FileUpload object, so try this: print file.__dict__ and you will find out that it has a method called file.read() which returns the data of the uploaded file. Cheers, Gregor! -----Original Message----- From: "Menno Brandsen" <menno(a)zreal.net> To: <zope-dev(a)zope.org> Date: Fri, 16 Mar 2001 03:46:45 +0100 Subject: [Zope-dev] (no subject) I have a question regarding images in a MySQL Database I'm trying to insert (and retrieve) images into a mysql database I use a standard upload form and a normal insert statement in the sql. The output i get is this : <ZPublisher.HTTPRequest.FileUpload instance at 86550c8> which is clearly not the correct data Can someone help me out with this, i need to get the data from the image in some sort of way, but i dont know how to do this ! Friendly greetings, Menno Brandsen

1 0

Adding ZClass Instances via Python
by Edmund Goppelt 16 Mar '01

16 Mar '01

Ok, I know there's a howto with a working solution to this problem, but this is *still* killing me: How does one add a ZClass Instance in a way analagous to adding, say, a DTML Document in a Python script? With the dtml document, it's easy: container.manage_addProduct['OFSP'].addDTMLDocument('anid', 'atitle','a file') I've tried the following, which don't work, as well as a variety of permutations and combinations involving container & context. constructor.Bill_add(None, context) constructor.Bill_add(container, cons, REQUEST) # Is this how one sets the REQUEST variable from a script? Can the # REQUEST variable be set from any valid Zope object, e.g,: # Anywhere.Anyobject.REQUEST.set('dfkjd', 123) will change the # variable dfkjd in the REQUEST object? container.REQUEST.set('id', '9389483484') container.REQUEST.set('title', 'a title') constructor=container.manage_addProduct['Bill'] The problem seems to have something to do with the getting the contexts right and getting the REQUEST info. passed to the constructor, but I'm just guessing at this point. Bill_add is the standard dtml method constructor created by the ZClass product. -- Ed Goppelt

2 1

[ANN] LDAPUserManager Released
by Jens Vagelpohl 16 Mar '01

16 Mar '01

The LDAPUserManager is a LDAP user record administration tool to be used in conjunction with the LDAPLoginAdapter. It allows the site manager to search, create, edit and delete user records that are stored on an LDAP server, thereby completing the Zope user management functionality already offered by the LDAPLoginAdapter. You can view some of the documentation and download the software at http://www.dataflake.org/software/ldapusermanager/. The LDAPLoginAdapter, now at 1.0beta3, can be found at http://www.dataflake.org/software/ldaploginadapter/. A Tracker at that same address allows you to easily file bug reports or feature requests for this product. jens

1 0