Re: [Zope-dev] Calendar tag 0.9.6 breaks with 2.2.0b3??
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: [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Calendar tag 0.9.6 breaks with 2.2.0b3??
"Dr. Ross Lazarus" wrote: > > > The offending line in CalendarTag.py is > > > > > > ns = namespace(self, > > > date = date, > > > mode = self.mode, > > > firstday = firstday, > > > setCalendar = self.setCalendar_, > > > getCalendar = self.getCalendar_, > > > linkDate = self.linkDate_ > > > )[0] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Calendar tag 0.9.6 breaks with 2.2.0b3??
"Dr. Ross Lazarus" wrote: > The point that I find hard to understand is that namespace in DT_Util > has changed from 2.1.6 as follows > > ===2.1.6== > class namespace_: > pass > > def namespace(self, **kw): > """Create a tuple consisting of a single instance whos attributes > are > provided as keyword arguments.""" > r=namespace_() > d=r.__dict__ > for k, v in kw.items(): d[k]=v > return r, > > 2.2.0b3 > class namespace_: > __allow_access_to_unprotected_subobjects__=1 > > def namespace(self, **kw): > """Create a tuple consisting of a single instance whos attributes > are > provided as keyword arguments.""" > return apply(self, (), kw) > > Now, I can easily put the old definition back and it might work - but > I'm not in a position to understand why the method has changed from what > looks like a simple dictionary construction to the apply function - > which doesn't seem to have anything to do with the namespace_ class !! In Zope 2.1.6 and before we had two ways of creating a new namespace: _() and _.namespace(). The former was implemented in C and the latter was in Python, but they did virtually the same thing (and there certainly wasn't any reason to believe they should do anything different.) So we merged the two implementations into one by causing the namespace() method to call the _() method, implemented in cDocumentTemplate.py. AFAIK the namespace_ class definition was left in by accident. It now does absolutely nothing. There have been more problems with the merge than expected. But we are engineers--the last thing we want is code bloat by reverting to the old method. Instead we'd like to get bugs truly corrected. So I'll plan to look into this problem. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Calendar tag 0.9.6 breaks with 2.2.0b3??
Thanks for the help. Summary: CalendarTag works fine in 2.1.6 but is broken in 2.20b3. __call__ is mapped to render(self,md) - this is the same for all dtml tags AFAIK. The point that I find hard to understand is that namespace in DT_Util has changed from 2.1.6 as follows ===2.1.6== class namespace_: pass def namespace(self, **kw): """Create a tuple consisting of a single instance whos attributes are provided as keyword arguments.""" r=namespace_() d=r.__dict__ for k, v in kw.items(): d[k]=v return r, 2.2.0b3 class namespace_: __allow_access_to_unprotected_subobjects__=1 def namespace(self, **kw): """Create a tuple consisting of a single instance whos attributes are provided as keyword arguments.""" return apply(self, (), kw) Now, I can easily put the old definition back and it might work - but I'm not in a position to understand why the method has changed from what looks like a simple dictionary construction to the apply function - which doesn't seem to have anything to do with the namespace_ class !! Brian?? Dieter Maurer wrote: > The "self", more precisely, its "__call__" gets the keyword > "linkDate" which it does not (no longer) likes to have. > > Dr. Ross Lazarus writes: > > Trying the new 2.2.0b3 zope. > > One zclass using ty's calendar tag now breaks with an error message I > > just cannot figure out - > > > > Error Type: TypeError > > Error Value: unexpected keyword argument: linkDate > > > > File /usr/local/zope/zope22b3/lib/python/DocumentTemplate/DT_Util.py, > > line 262, in namespace > > TypeError: (see above) > > > > I added __allow_access_to_unprotected_subobjects__=1 to the CalendarTag > > class just in case. > > > > The offending line in CalendarTag.py is > > > > ns = namespace(self, > > date = date, > > mode = self.mode, > > firstday = firstday, > > setCalendar = self.setCalendar_, > > getCalendar = self.getCalendar_, > > linkDate = self.linkDate_ > > )[0] > > > > > > namespace in DT_Util seems harmless enough - > > > > def namespace(self, **kw): > > """Create a tuple consisting of a single instance whos attributes are > > provided as keyword arguments.""" > > return apply(self, (), kw) > The "self", more precisely, its "__call__" gets the keyword > "linkDate" which it does not (no longer) likes to have. > > Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
[Zope-dev] EMarket and 2.2.0b3
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Calendar tag 0.9.6 breaks with 2.2.0b3??
Dr. Ross Lazarus writes: > Trying the new 2.2.0b3 zope. > One zclass using ty's calendar tag now breaks with an error message I > just cannot figure out - > > Error Type: TypeError > Error Value: unexpected keyword argument: linkDate > > File /usr/local/zope/zope22b3/lib/python/DocumentTemplate/DT_Util.py, > line 262, in namespace > TypeError: (see above) > > I added __allow_access_to_unprotected_subobjects__=1 to the CalendarTag > class just in case. > > The offending line in CalendarTag.py is > > ns = namespace(self, > date = date, > mode = self.mode, > firstday = firstday, > setCalendar = self.setCalendar_, > getCalendar = self.getCalendar_, > linkDate = self.linkDate_ > )[0] > > > namespace in DT_Util seems harmless enough - > > def namespace(self, **kw): > """Create a tuple consisting of a single instance whos attributes are > provided as keyword arguments.""" > return apply(self, (), kw) The "self", more precisely, its "__call__" gets the keyword "linkDate" which it does not (no longer) likes to have. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] ZTopic displays wrong tabs
Steve Alexander wrote: > > > > > > > Edit catalog search criterion number > on Catalog . Or, I could have used the less-clear one-liner: Any preference? -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
[Zope-dev] ZTopic displays wrong tabs
Hi folks, I'm using ZTopic. One thing I've noticed about the management interface is that, although an appropriate tab is highlighted when you click that tab, if you go to a subsequent screen, often "contents" will erroneously become the highlighted tab. This is causing problems as I explain to non-technical folk how to use ZTopics. I say "select the contents tab", and they say "but the contents tab **is** selected!". I have a fix for this, but the real problem is in the logic of lib/python/App/manage_tabs.dtml: Here, the variable 'a_' represents the "active" tab. If the last part of the URL matches one of the manage_options of the current object, then that tab will be the highlighted one. Otherwise, the first tab will be highlighted. It should ideally be possible to tell manage_tabs what tab should be highlighted, imperatively, when required. However, in the absence of such a mechanism, I have changed the DTML files in ZTopic like this: The form searchEdit.dtml is really part of the "Search Criteria" logic, so I want that tab highlighted. That tab's action attribute is called "editForm". Therefore, in the file searchEdit.dtml, I replace this: Edit catalog search criterion number on Catalog . With this: Edit catalog search criterion number on Catalog . (I modernised the to along the way.) To get the full effect, you'd need to do a similar trick with the other dtml files in ZTopic. Any takers for a full patch? Or, is there a better way of doing this that I don't know about? -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
[Zope-dev] ZPatterns: DropZone example
Hi folks, I've been looking at the DropZone example Phillip Eby provided on the ZPatterns Wiki. http://www.zope.org/Members/pje/Wikis/ZPatterns/DropZoneExample I've decided to start implementing it, so as to give myself an educational experience in using ZPatterns. I have an open question: The suggested specialists in the Accounting framework are: Invoices Orders Customers Products What I'm finding is that these are just the White-box specialists. A clean design would seem to want all the specialists above, plus at least one Black-box specialist to do the "heavy lifting. Let's call it the "AccountingProcessor" specialist. Now, if I had a third-party accounts package (something by Sage perhaps), I could make the AccountingProcessor specialist expose various functions to the four other White-box specialists. It would implement these by making equivalent calls on the underlying accounting package. I could also swap the heavy-lifting portion of my framework by swapping the black-box AccountingProcessor specialist for one that talks to some software by Quicken, or perhaps some software that is written in Python as a conventional Zope product. The same goes for the Resource Scheduling framework. We have some White-box specialists, ripe for customisation: Resources Reservations ResourceUsers And then for the heavy-lifting we have the black-box ResourceScheduler specialist. Again, this might be a Zope Python Product, or it might be an interface to some application written on top of Microsoft Exchange. Are specialists intended to be placed inside other specialists, as "contents"? So in this case, would the white-box specialists live inside the black-box specialist -- so they become the customisable aspects of the overall framework? Or would both black-box and white-box specialists live inside an uber-specialist? Or is this just down to taste? -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
[Zope-dev] Comments on ZPatterns
> > "Phillip J. Eby" wrote: > > > At 02:33 PM 6/11/00 -0600, Shane Hathaway wrote: > > > >I believe I have come to understand the basics of ZPatterns and would > > > >like to be sure I understand correctly, as well as help others > > > >understand also. Feel free to flame me if I've got this wrong, but: I've read all the ZPatterns Wiki and I'm just taking tentative steps to playing with LoginManager. I think the concepts are very cool but I see two problems: 1. Too much jargon... by far... Lots of complicated words that are meanlingless to the layman and don't help to convey the concepts. This is compounded by the standard Zope problem of minimal documentation aimed at the advanced developer. Can someone who understadns this all take the time to write a ZPatterns guide to compliment the Wiki and maybe simplify or explain in great detail all the terms (especially the new ones that have popped up in the last few weeks)? 2. Feature runaway. It seems every day something new (and more confusing) has been added to ZPatterns. I think ZPatterns will only work if it is kept as simple and functional as possible. My view (bearing in mind my limited understanding ;-) would be to concentrate on Containers, Container Groups and Plugins on the one front and Racks, Specialists and the various providers and agents on the other. Comments always welcome, cheers, Chris PS: The main reason I'm writing this is because I think ZPatterns are very very cool but may well get ignored because no-one understands them and they're too buggy and complicated to get working :/ ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Racks and Specialists Simplified
Shane Hathaway wrote: > > "Phillip J. Eby" wrote: > > At 02:33 PM 6/11/00 -0600, Shane Hathaway wrote: > > >I believe I have come to understand the basics of ZPatterns and would > > >like to be sure I understand correctly, as well as help others > > >understand also. > > > > Bravo! An exquisite introduction to the purpose of ZPatterns. May I post > > an edited version of your message to the ZPatterns Wiki, and make it or > > subsequently edited versions a part of the ZPatterns documentation? (With > > attribution, of course.) > > By all means! Thank you. The truth is that several of us at DC have > had trouble making sense of it all, so I wrote it not only for the > community, but DC and myself as well. :-) I just looked over the ZPatterns Wiki for Shane's explanation, but I can't find it. If it isn't there (hiding somewhere), perhaps I can add it from Shane's original email? -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
[Zope-dev] Prototyped folders?
Hi Hamish, I've answered your message in Zope-Dev, as this seems to be more of a developers' question. Hamish wrote: > If a folder doesn't itself contain a required object or method, I'd > like to have another folder looked in instead. The fall-back folder > won't necessarily (and often can't) be higher in the hierarchy, so > acquisition doesn't seem to be a solution. This looks like a job for a Python class that uses the new Traversal interface. http://www.zope.org/Members/michel/Projects/Interfaces/Traversal Your requirements sound very much like those for Shane Hathaway's Transparent Folders product, except that instead of briefly diverting acquisition into the transparent folder, you want to briefly divert acquisition into some other arbitrary folder. Last I heard, Shane was going to revitalize Transparent Folders when the various interfaces it uses are finalized for Zope 2.2. I suggest that after Shane has re-released his product, you make a product based on Transparent Folders that works in this slightly different way. Or, if it is appropriate, consider your changes an enhancement to Transparent Folders, and offer it as a patch. If you don't have sufficient python-hacking-zope-hacking-Zen to do it yourself, I think I might have a go (and hopefully learn some Zope internals Zen in the process). Transparent Folders were here: http://www.zope.org/Members/hathawsh/ - but the link to them is broken -- I guess because the product was withdrawn as there was a problem with it under Zope 2.1.6. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Zope2.2.0b3 Image/File object create/upload bug (w/patch)
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
[EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
Re: [Zope-dev] Confera fix
Hmmm, you could just use Squishdot 0.4.1 with the 'plain' style, it looks and behaves pretty much identically to Confera except it works (although I'm sure it has bugs ;-) and is maintained (by me ;-) which, sadly, I don't think Confera is. HTH, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
RE: [Zope-dev] Confera fix
Hi I use confera-1.3.2-mtg. This version does not use ts_regex. I needed a small patch to make it handle newlines correctly. I cannot find a link confera-1.3.2-mtg so I attach the mtg patch as well. Gabor Melis On 27-Jun-2000 MIME :[EMAIL PROTECTED] wrote: > Attached is a slightly modified Confera.py that does not require the > ts_regex > python package (something I do not have on my system and cant seem to > find - and yet something Confera will choke on during message posting if > it doesn't exist) > > I've put the moded Confera.py up in my member folder at: > http://www.zope.org/Members/Coventry/Confera_Fix > > Anyone who has problems utilizing Confera due to no ts_regex may find > this useful. > > Does anyone know where to find ts_regex by itself? > > If its not readily available (I cannot find it) I'd suggest making a > minor > point release of Confera that does not need it. > > <> > mtg-patch confera-nl-patch
[Zope-dev] cut and paste zclass instances broken in 2.2.0b3?
Another gremlin has just bitten hard.
I have a nested zclass - zclass (link object) within a zclass ('problem'
object) within a zclass ('problem container' object).
In 2.1.6, no problems using manage_cutObject and manage_pasteObject to
move the link objects around between problems. In 2.2.0b3, I'm told that
the link object instance "doesn't support this operation" - manual cut
and paste from the management interface also fails.
h...
something broken?
--
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: [EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
