July 2000 - Zope-Dev

System error
by Andre Schubert 24 Jul '00

24 Jul '00

Hi, I have a problem on deleting a folder. I have made a product, which has some bugs. After i have added it to a Folder named test i can't open the Folder and a can't delete the Folder test because a System Error occurs. The following Error message occurs:  Who can help to delete this Folder. mfg as

1 0

namespace ??
by Marcus Mendes 24 Jul '00

24 Jul '00

Hello, How can I get the contents of variable out of my <dtml-in> </dtml-in> code? For example: <dtml-in "_['sequence-item'].objectValues(['TSubRegiao'])"> <dtml-call "REQUEST.set('HORA', horacondicaoatual)"> </dtml-in> I need get the variable HORA and I couldn't. Thanks Marcus Mendes

3 2

mxODBC, ExtensionClass.Missing and Results puzzle???
by Jay, Dylan 24 Jul '00

24 Jul '00

I've compiled up a mxODBC DA for use under windows so that multi-threaded odbc drivers can be me used in a multi-threaded way. This works good so far except for one aspect. NULL values are being returned as "None" objects. This seems reasonable but it is not how ZODBC returns results. It will return a NULL as a "Missing" object (whatever that is?). I can't find any documentation to find out what this object is or means. My biggest problem is that the UserDB product doesn't like None objects being return for passwords. It seemed to handle the Missing objects fine. To add to the mystery I noticed that the result object returned by an sql method connected to first ZODBC and then ZmxODBC was of two different types. ZmxODBC was returning a ZRDB.Results object. ZODBC was returning a ZRDB.RDB.DatabaseResults object. The latter is apparently a "Class for reading RDB files" but as this is the only documentation I can find I have no idea how it differs from the ZRDB.Results class or rather why ZODBC returns it and thus has NULL's replaced Missing objects. Can anyone shed any light on any of this? ---- Dylan Jay mailto:djay@avaya.com Avaya Communication Tel: +61 2 9886-8961 Level 5, 15 Talavera Road FAX: +61 2 9352 9224 Nth Ryde NSW 2113 Mobile:+61 409 606 171 AUSTRALIA ICQ: 520341

1 0

DateTime.py
by Steve Alexander 23 Jul '00

23 Jul '00

There's a problem with strftime() in DateTime.py. Try this DTML method to see: ---- <dtml-var standard_html_header> <dtml-let time1="_.DateTime('2000/07/23 BST')"> Time: <dtml-var time1> <br> Time: <dtml-var time1 fmt=Date> <br> Time: <dtml-var time1 fmt="DayOfWeek"> <br> Bad Time: <dtml-var time1 fmt="%a, %d %B %Y %Z"> <br> Time: <dtml-var "time1.fCommonZ()"> <br> </dtml-let> <dtml-let time1="_.DateTime('2000/07/23 GMT')"> Time: <dtml-var time1> <br> Time: <dtml-var time1 fmt=Date> <br> Time: <dtml-var time1 fmt="DayOfWeek"> <br> Time: <dtml-var time1 fmt="%a, %d %B %Y %Z"> <br> Time: <dtml-var "time1.fCommonZ()"> <br> </dtml-let> <dtml-var standard_html_footer> ---- Note that the time given in the line "Bad Time:" above is actually wrong -- it reports itself to be in GMT, but gives the time as one hour behind. If you specify a date as YYYY/MM/DD, then the date that is stored is (quite reasonably) midnight on that day, in your timezone. This gets rendered back into days correctly for methods such as DateTime.day(), as these methods directly ask the DateTime instance for what it thinks the day is. The instance replies in the context of its own timezone (as given in the constructor, or the local timezone if none was given), and so it returns the expected result. If you use the strftime() method, by using fmt="%d %H %Z" or whatever, instead of asking the DateTime instance to do the formatting, the formatting is delegated to the Python time module. Unfortunately, at any particular time, the Python "time" module only knows about two timezones: Your local one (with and without daylight savings) and GMT. Therefore, in any other timezones, Pythons time.strftime() cannot correctly render the time. This is particularly apparent in the current DateTime.py, because its strftime method just interprets the internal representation of the time as GMT, whatever. We can fix this easily: *** lib/python/DateTime/DateTime.py Sun Jul 23 20:03:05 2000 --- lib/python/DateTime/DateTime.old.py Sun Jul 23 20:03:04 2000 *************** *** 1376,1382 **** return millis def strftime(self, format): ! return strftime(format, gmtime(self.toZone('GMT').timeTime())) # General formats from previous DateTime def Date(self): --- 1376,1382 ---- return millis def strftime(self, format): ! return strftime(format, gmtime(self.timeTime())) # General formats from previous DateTime def Date(self): Now, at least, the time will be reported correctly, although not really usefully if you want to have the time formatted in the timezone given to the DateTime instance. Also, this patch will cause formatting calls to create a new DateTime instance if the instance you want to format is not in timezone GMT+0. The only general solution that I can see is to replicate the formatting algorithms of the time module in DateTime.py, but written so that they take account of timezones. There is another issue: When I call _.DateTime('2000-07-23'), what do I mean? The current implementation of DateTime interprets that as "midnight (the earliest possible time) on 2000-07-23, interpreted in the local timezone". However, if I'm being naive, I might think that I'm refering to a Day, and that the Day should be the same day no matter what timezone I put it into. In that case, the DateTime module needs rewriting to have a sense of precision built into it: If I specify a time to the day, I get the latter behaviour. If I specify the time more precisely, I get the current behaviour. Another approach would be to make _.DateTime('2000-07-23') mean Midday, GMT rather than Midnight, local time. That would give the latter behaviour for most timezones at most times; the exceptions being places near the international date line that are in daylight savings time. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net

1 2

cut/paste catalogue aware zclass instances still broken in 2.20?
by Dr. Ross Lazarus 23 Jul '00

23 Jul '00

Has anyone else noticed a problem with pasting cut or copied catalogue-aware zclass instances? The collector item #1371 I submitted on June 27 seems still to be present in 2.20 final - sorry, I don't have a patch... It's a function I need and duplicating it without using manage_pasteObject after a manage_cutObject is going to be painful. The manage_cutObject and manage_copyObject functions seem happy enough, but when I do a manage_pasteObject, I get "the object foobar does not support this operation" - no traceback. Zope-2.2.0 source on Redhat linux 6.1

2 2

Problem acquiring via a newly created object
by Richard Barrett 21 Jul '00

21 Jul '00

I'm stumbling to find a solution to the following problem. Using python I have created two classes which respectively derive from the standard Zope Folder class and DTMLDocument class. My classes (and some others yet to be written) are intended for use when requirements stipulate that published material must be held/protected in RCS as well as being served via Zope. I've elected to put an attribute called 'web_RCS_root' at the top of the Zope object hierarchy which contains the server local file system path under which files to be held by RCS. When instances of the Folder derived class are created, the add function creates a file system folder below the 'web_RCS_root'. The add function for my folderish objects effectively creates a directory hierachy in the file system isomorphic to the hierachy of the URL's being served by Zope. Instances of my DTMLDocument derived class are only allowed within my Folder derived class. The add document function that creates them and the edit function for them use RCS check-in to preserve copies of the document contents. I'm using the following python expression in the manage_addFolder and manage_addDocument functions to determine the location in the file system for the RCS backup of the data. rcspath = os.path.normpath(getattr(self, 'website_RCS_root') + \ '/' + self.absolute_url(1) + \ '/' + ob.id) As you can see it depends an acquiring the value of the 'website_RCS_root' attribute from its containment environment. This works fine for both folder-like and document-like classes if the add functions are called from the management interface. However, I want to create an instance of my document class within the containment of an instance of my folder class while creating that instance of my folder class. Just like creating a public interface (index_html) as part of creating a regular folder, which is what my code is based on. I'm doing this by calling my manage_addDocument function from within the my manage_addFolder function. But this fails with Zope reporting an AttributeError of the acquired attribute 'website_RCS_root'. My best guess as to why goes something like: "until the transaction in which the folder is created is committed, the acquisition of attributes higher in the containment hierarchy will fail. As you are trying to create the document in the same transaction this is bound to fail", but I've no proof this is the problem. What's going wrong and what's a good solution to the problem. I'm working with Zope 2.1.6 running under Suse 6.4 Linux on an x86 processor. ------------------------------------------------------------------ Richard Barrett, PostPoint 27, e-mail:r.barrett@ftel.co.uk Fujitsu Telecommunications Europe Ltd, tel: (44) 121 717 6337 Solihull Parkway, Birmingham Business Park, B37 7YU, England "Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well armed lamb contesting the vote." Benjamin Franklin, 1759 ------------------------------------------------------------------

3 3

dtml-in problem at Zope 2.2.0
by Jacques Exelrud 21 Jul '00

21 Jul '00

Here is the scenario: On Folder X I have a Z ODBC Database Connection and some Z SQL Method. I´m sure all are working because I´ve tested them all. Under Folder X I have another Folder Y with an index_html with the following: <dtml-var standard_html_header> <dtml-in qryatparentfolder> </dtml-in> <dtml-var standard_html_footer> No need to include anything inside the dtml-in. This works fine with Zope 2.1.6 but with Zope 2.2.0 I get the user/password dialog from the browser and I can give whatever user/password combination but none of them works. Thanks in advance, Jacques

1 0

namespace problem??
by Marcus Mendes 21 Jul '00

21 Jul '00

Hello, How can I get the contents of variable out of my <dtml-in> </dtml-in> code? For example: <dtml-in "_['sequence-item'].objectValues(['TSubRegiao'])"> <dtml-call "REQUEST.set('HORA', horacondicaoatual)"> </dtml-in> I need get the variable HORA and I couldn't. Thanks Marcus Mendes

1 0

zzLocale 0-0-3a released on Zope Japan
by Yves-Eric Martin 21 Jul '00

21 Jul '00

Hi Zopistas, This is the second alpha release of zzLocale, a Zope locale support Product. zzLocale provides a framework for Zope interface internationalization (Zope and Products management screens). The localization is done on a per request basis, which allows developers from different countries to work on the same Zope while each of them having an interface in his native language. With zzLocale, Product developers can easily provide localized interfaces for their Products. All that is needed is to put the localized interface DTML templates in a "locales/[lang]" subdirectory of the Product, and zzLocale does the rest. This version of zzLocale is pretty useable, and usually falls back nicely when something goes wrong. However, it is still alpha, and we would not recommend using it on a production server. This release includes a complete (I mean, as complete as current zzLocale features permit) French interface, and a partial Japanese one. Tranlators are welcome to provide other languages. Please send us your translated templates so that we can include them in the next release. For more information and download: http://www.zope.ne.jp/users/yemartin/zzLocale Regards, -- Yves-Eric Martin Digital Garage Inc. yemartin(a)garage.co.jp

1 0

Datebug?
by Peter Arvidsson 21 Jul '00

21 Jul '00

I have encountered a strange and irritating problem. As I live in Sweden we use timezone 'GMT+1'. I have a form like this: <dtml-var standard_html_header> <form action="a"> <input type="text" size="15" name="date:date" value="<dtml-var ZopeTime fmt=%Y-%m-%d>"> <input type="submit"> </form> <dtml-var standard_html_footer> And when I press submit I come to this page: <dtml-var standard_html_header> <input type="text" value="<dtml-var date fmt=%Y-%m-%d>"> <dtml-var standard_html_footer> The input field are correctly displaying the date (in GMT+1) but when I submit the form and use the "fmt" the date is displayed with a decrease of 24 hours. Like if I write 2000-07-21 in the input-field the next page will display 2000-07-20. I I dont format the date on the second page the same date will be shown. It cant really be a timezone issue because it is decreasing the date by 24 hours and I only live 1 hour from GMT. The date on my computer and the server are correct. Does someone knows why this happens when I use "fmt" or is this a DateTime bug?

1 0