June 2000 - Zope-Dev

Re: [Zope-dev] Product Data Storage
by Josh Zeidner 03 Jul '00

03 Jul '00

You should look into using ZCatalog for this purpose. -josh zeidner >I have an interesting issue which I don't think has been raised. But >instead of solving the issue myself I thought I would share it with you >guys/gals and see what you think. > >I am currently working on a Zope MailIn product, which allows you to send >emails directly in to Zope. >Version 0.1 can be found at: >http://www.zope.org/Members/NIP/ZMailIn > >In version 0.2 I plan to have a ZMailIn python product which will handle >the >Zope side of things and behave a bit like a client. For example you could >add a ZMailIn product instance in to Zope and configure it to receive all >emails for bob(a)bobscompany.com and provide a method to execute upon mail >arrival. > >This is great and you could have n ZMailIn product instances throughout >your >Zope site and in any position. > >When email arrives I need to find all the ZMailIn instances within the ZODB >and hand the email to the correct one. > >I have decided AGAINST searching the ZODB for instances of ZMailIn because >that is just too scary, hideously inefficient and I don't want to go there. >Instead I thought of keeping an up-to-date list of where all the current >instances where held. My original idea was to get the ZMailIn product to >write a file in to the /lib/python/Products/ZMailIn directory, which >shouldn't cause any problems that I can see. > >However, It had occurred to me that with the current growth of Zope it was >going to become more popular that separate Zope instances of the same >product may need to share some data. > >So my question is this: >What are peoples opinions on storing shared product data? Where should it >be placed? Should this ability be added to Zope as a standard? > >Thanks in advance. >-Andy Dawkins >(New Information Paradigms Ltd) > > >_______________________________________________ >Zope-Dev maillist - Zope-Dev(a)zope.org >http://lists.zope.org/mailman/listinfo/zope-dev >** No cross posts or HTML encoding! ** >(Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

5 5

Re: [Zope-dev] Zope2.2.0b3 Image/File object create/upload bug (w/patch)
by Adam Karpierz 01 Jul '00

01 Jul '00

Please, can you explain me why this bug and path was retracted from Collector with message ?: "Retracted by submitter (in Zope-Dev mailinglist, forgot to define USE_EXTENSION_CLASS)." This path intended for 'official' version 2.2.0b3, _not only_ for version compiled from sources. Please compare old good code(2.1.6), with buggy new code(2.2.0b3) for clarification why new code is buggy: lib/python/OFS/Image.py ----------old(2.1.6):------------------- def _read_data(self, file): n=1<<16 if type(file) is StringType: size=len(file) if size < n: return file, size return Pdata(file), size seek=file.seek read=file.read ... -------new buggy ('official' 2.2.0b3)------------- def _read_data(self, file): n=1<<16 if type(file) is StringType: size=len(file) if size < n: return file, size return Pdata(file), size if file.__class__ is Pdata: ## !!! this new code is buggy because if type(file) is not 'instance', size=len(file) ## !!! file variable don't have __class__ attribute (eg: if type(file) == FileType) return file, size ## !!! First is needed check out if file is 'instance' type. Would be: ## !!! if type(file) is InstanceType and file.__class__ is Pdata: seek=file.seek read=file.read ... ------------------------------------------ This bug makes impossible to use code which works ok with old Zope-s (prior 2.2.0) eg: f = open('path/image.gif', 'rb') OFS.Image.manage_addImage(root, 'logo', f, 'logo') f.close() With Zope 2.2.0b3 this code produces bug with traceback eg: """ Zope Error Zope has encountered an error while publishing this resource. Error Type: AttributeError Error Value: __class__  """ Simple path which I was send to Collector avoid this problem. Adam Karpierz karpierz(a)itl.pl

2 1

FWIW, ZCVSMixin now at 0.1.1... and rising. ;-)
by Steve Spicklemire 01 Jul '00

01 Jul '00

Hi Folks, I don't know if anyone out there is actually trying to *use* my ZCVSMixin/ZCVS Folder stuff, but if you are you certainly want to get the latest release, ZCVSMixin-0.1.1.tgz from the zope.org site: http://www.zope.org/Members/sspickle/ZCVSMixin I put some screenshots up there so you can see what it looks like at: http://www.zope.org/Members/sspickle I've also found it useful for managing Python products and other software through the web! I have had a couple of minor 'breakthrough's that *seem* cool, but I might just be fooling myself. If an object is not folderish I guess that it's 'simple' so I export it as XML with the following code: def doExport( conn, oid, file=None): counter=0 if file is None: file=TemporaryFile() elif type(file) is StringType: file=open(file,'w+b') write=file.write write('<?xml version="1.0"?>\012<ZopeData>\012') version='' ref=referencesf oids=[oid] done_oids={} done=done_oids.has_key load=conn._storage.load while oids: oid=oids[0] del oids[0] if done(oid): continue done_oids[oid]=1 try: p, serial = load(oid, version) except: pass # Ick, a broken reference else: ref(p, oids) write(conn.XMLrecord(buildOID(counter),len(p),p)) counter = counter + 1 write('</ZopeData>\n') return file def buildOID( value ): return '\000\000\000\000' + struct.pack('!l', value) This way the XML always starts with '0' as a base oid. I experimented a little and the xmlimport stuff doesn't seem to use the 'oid' unless an object is 'complex' (i.e., self references etc... ). Anyway this has the happy effect of making the xml for a simple object the same every time it is exported so diff's make sense etc... If objects are 'folderish' or 'complex' (and the user is permitted to dictate this when objects are added to CVS), they are exported as 'zexp' files and cvs adds them as 'binary'. I was having trouble with certain kinds of object's xml representation. I decided that this was really an xml implementation problem, since I couldn't reliably export these as xml through the normal Zope export mechanism either. Anyway.. let me know what you think if you are using this stuff! Finally I'm aware that there are also security issues with the way this works now. I need to look at all the things a user might need to do and eliminate some of the 'type in' arguments that are in the product now. These arguments wind up on 'os.system' calls, and could be abused by a ill-meaning user (with access to the CVS Admin page!) Any thoughts there? thanks, -steve

3 4

EMarket and 2.2.0b3
by R. David Murray 01 Jul '00

01 Jul '00

OK, so I didn't get very far in tracking down what inside EMarket is triggering the wierd auth behavior, because I had to run a bunch of tests against b3, where the behavior has changed from that of b2. For this testing my method of determining if "things are weird" is to see if I get prompted for authentication if I access the "/manage_main" URL. Weird means I don't get prompted. Under b2, installing EMarket with a dummy empty __init__.py file caused the weird behavour. Under b3, that test does not. However, the EMarket __init__.py file with any of the imports for the submodules uncommented *does* cause the weird behavior. Farther than that I haven't gotten yet. My tests give me some other interesting things to report, however. After installing b3, I confirm that the site is working and I can view the root index_html file normally. If I then copy my test Data.fs from the b2 installation, the b3 instance fails to show the root index_html, giving an error message of a key error on URL on the last line of traverse in BaseRequest.py. Now here's the weird thing: if I then *delete* the Data.fs file, and restart Zope, *I continue to get that same error*. I didn't try to track that any further, but it unnerves me. Second, the patch, supplied by someone else, that I reposted here that fixed the "a_" KeyError after EMarket was installed in b2, if applied to b3 *causes* that "a_" error to appear. Since this patch was reportedly added to the CVS, I think there is something here that needs to get cleared up before 2.2 final. I'll work on this some more tomorrow, but so far I'm nowhere near finding what code might be involved in this set of errors. Has anyone seen the aforementioned "weird problem" with any products other than EMarket and eTailor? --RDM

2 5

Re: [Zope-dev] Using Java-Script with DTML
by Hung Jung Lu 30 Jun '00

30 Jun '00

--- In zope(a)egroups.com, Thomas Weholt <Thomas@c...> wrote: ><script language="javascript1.2> > >function ShowStuff(params){ > > var text = "<dtml-in expr="sqlMethod(some_id=params>"  > alert (text); >} > ></script> I think I know what you are talking about. But you have to really keep your mind straight about one thing: DTML runs with the CPU on the server side, JavaScript runs with the CPU on the client side. In other words, by the time you are running Javascript, you CAN'T access your database records. I have done a lot of things in displaying dynamic pull-down menus. E.g: you choose a state from one pull down menu, and the content of another pulldown menu is automatically changed to the list of cities within that particular state. When you click on a state, you CAN'T query your database for the list of its cities. It's too late, your code is already running on the client side. So what should you do? What you should do is to pre-generate JavaScript arrays, storing the names of all the cities for all the states. That being said, there is one more caveat. When you pre-render your database records into JavaScript arrays, you have to be careful about quoting. I don't know whether there are any string format quoting in DTML suitable for rendering into JavaScript (the <dtml-sqltest ... type=string> comes to mind, but I am not sure it works outside ZSQL methods), I ended up implementing my own external method to quote Python strings into JavaScript strings. If you still don't understand what I mean, consider a python string 'He said, "no".' stored in your DTML variable mystring, that is, something like: <dtml-call "REQUEST.set('mystring', 'He said, "no".')"> and you pre-render it into JavaScript code x = "<dtml-var mystring>"; It won't work. Because if you look at the source of your JavaScript, you will see: x = "He said, "no"."; regards, Hung Jung ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

2 1

Question
by Jonathan Desp 30 Jun '00

30 Jun '00

Hi, How I can upload 900 files into zope, in one shot ? I cannot use FTP, with the port 8021, I cannot use load site from itamar, because there is a bug. Maybe WebDav ? But I don't know how to use it. my email is: mailto:jonathandesp@atoma.f2s.com, if you want to help me to fix that problem, I searched a solutions since 3 days. -- Very truly yours, <><><><><><><><><><><><><><> Jonathan Desp Atoma Matter will become Software http://www.atoma.f2s.com <><><><><><><><><><><><><><>

1 0

Re: [Zope-dev] Calendar tag 0.9.6 breaks with 2.2.0b3??
by Dr. Ross Lazarus 29 Jun '00

29 Jun '00

Shane - it's a shocking thing to post untested patches - particularly when they work !!!! I just tested this quickly on 2.1.6 and 22b3 and it seems fine. Thank you!. Ok, what's the way forward here - how do we make sure that a 2.2 clean CalendarTag product appears in the Products download area on zope.org??? How do we make sure every product available for download on zope.org is clearly marked as either untested for 2.2; broken in 2.2; 2.2 clean - otherwise many new zope users are going to be tearing their hair out patching stuff or giving up in disgust??? Who's going to go through each one and patch it as needed? The calendar tag is a good example - probably lots of folks out there using it - all are going to be bitten by this when they upgrade to 2.2x? > I haven't tried this, but I think if you change the "self" argument in > the namespace() call from CalendarTag to "md", the problem will be > resolved. I think that's what Ty meant to do, but the old mechanism > didn't care; it didn't even look at the first argument. In other words: > > > > > ns = namespace(md, > > > > date = date, > > > > mode = self.mode, > > > > firstday = firstday, > > > > setCalendar = self.setCalendar_, > > > > getCalendar = self.getCalendar_, > > > > linkDate = self.linkDate_ > > > > )[0] > > Of course, it's kinda crazy for me to be sending out untested patches to > other people's work. :-) But if this works, it will also be > backwards-compatible. > > Shane -- Dr Ross Lazarus Associate Professor and Sub-Dean for Information Technology Faculty of Medicine, Room 126A, A27, University of Sydney, Camperdown, NSW 2006, Australia Tel: (+61 2) 93514429 Mobile: +61414872482 Fax: (+61 2) 93516646 Email: rossl(a)med.usyd.edu.au

2 1

Unit testing an application's user interface
by Andrew Wilcox 29 Jun '00

29 Jun '00

Hello everybody, I've made some progress on unit testing my application's user interface. I'll share what I've got so far. For background, there was discussion on unit testing last February on zope-dev: http://lists.zope.org/pipermail/zope-dev/2000-February/003489.html http://lists.zope.org/pipermail/zope-dev/2000-February/003514.html http://lists.zope.org/pipermail/zope-dev/2000-February/003501.html An introduction to why do unit testing can be found at: http://www.extremeprogramming.org/rules/unittests.html First, I do start by splitting out business classes and other functionality that isn't dependent on Zope, and test these separately in isolation. This gives me a solid foundation of working and tested code to build upon. But I found that I have enough complexity in my user interface that I really need to test that as well. I experimented for a time with checking the HTML output of web requests. The framework would remotely submit http requests, walk through the web site, exercise various functionality, submit form requests, and check if the resultant HTML was correct. Unfortunately, as you might expect, the tests were quite fragile. Any change in the website, no matter how small, would produce different HTML and break all the tests. I found the HTML testing of some limited usefulness while refactoring, but I'd have to throw all the tests away as soon as I added any functionality. And checking the HTML output isn't good unit testing -- not small, focused tests of particular functionality. More thought was needed. One of the points unit testers make is to focus the time you put into writing unit tests to target where bugs are most likely. In my situation, I found I wasn't being bit by bugs in presentation, in the rendering of HTML from information in the ZODB. Where I was getting bugs slipping past me was in the more complex processing of when my form processing would update ZODB objects. With this realization, I came up with an approach that I have found very useful. Run a form submit (or other data changing web request) through Zope, and then check if objects in the ZODB have been updated as you'd expect. This is nice. You have a small piece of data going into the test (the form submit fields), and you can easily check particular attributes of affected objects in the ZODB. This is a good unit test: small, predictable, and you can code the test before implementing the functionality. It's a good fit for the pattern of bugs that I have in my own code. I check the form processing as well as the underlying updating of objects, because my code tends to have bugs in those areas. I'm not checking how the results get rendered (the HTML that comes back), because I usually don't have bugs in that area when the underlying code is correct and is getting its own unit testing. I check if objects in the ZODB are updated correctly. As an example, suppose I wanted to unit test the Zope user interface for editing DTML Documents. The familiar "Edit" tab has an input box for the document title and a text box for entering the content. The form submit is "manage_edit". If called remotely, the URL for editing a document named "TestDocument" would look like http://www.myzope.com/somepath/TestDocument/manage_edit with the "title" and "data" fields submitted as form elements. Here's an external method that will do this test, here checking if the title is updated properly. def testChangingDocument(self): try: document = self.TestDocument document.manage_edit(data="Hi, I'm a DTML Document", title="hello", SUBMIT='Change') assert document.title == "hello" finally: get_transaction().abort() return "Test was successful" I call "manage_edit" with the form data, and then check if the ZODB has been updated as I expect. The transaction abort in the "finally:" clause ensures that in all cases (whether the test is successful, the assertion fails, or an error occurs) changes to the ZODB will be backed out of and the database left unchanged. This lets me run lots of tests without them bumping into each other. My realworld tests tend to be more complicated, first setting up objects and then checking multiple things, but this is the essential framework. So far so good. There are some problems with this method of implementation though. What I really want to be doing is setting up the web request with the form fields, and then running my request through the Zope machinery. In my example above, I cheated and looked at the source code for manage_edit() to see how it wanted to be called. manage_edit() happens to declare the form fields it's looking for as arguments to the method, and Zope obligingly pulls those values out of the request and supplies them. But manage_edit() could have been written to pull the values out of the REQUEST.form, and I would have to call it differently. Getting the Zope machinery to process the request is trivial, of course, if I perform an actual web request remotely, such as by using httplib. But that makes it hard to check directly if the ZODB was updated in the way I'm expecting. So what I need to be doing is to plug into Zope at the right point, say here's my URL path and request variables, do your thing, get control back, and then have a chance check out what happened to the affected objects in the ZODB. Andrew

2 1

Alternate User Folders Broken in 2.1.6? HELP!!!
by jiva＠devware.com 29 Jun '00

29 Jun '00

It seems as if all the alternate user folders I have tried (GUF, UserDb, etc) all seem to be broken under 2.1.6 They worked fine in 2.1.4, but when I upgraded to 2.1.6 they broke!! HELP! I need to solve this ASAP! -- With/Without - and who'll deny it's what the fighting's all about? -- Pink Floyd

1 0

[ANN] FSSession-0-4-0
by Pavlos Christoforou 29 Jun '00

29 Jun '00

FSSession 0-4-0 is available at: http://www.zope.org/Members/gaaros/FSSession FSSession 0-4-0 corrects a bug in the transaction management. Now tpc_finish always succeeds and all the storing actions are performed in tpc_begin. tpc_finish simply performs a 'rename' operation which is atomic in Unix. Pavlos

1 0