Re: [Zope-dev] Re: [Zope] Optimization and speed
On Sat, 15 Jul 2000 13:19:33 -0700, Stephan Richter [EMAIL PROTECTED] wrote: I take that back in the previous mail to Steve about the large table. We have one and I split the header from the rest as you suggested. But since it is not streaming the information, it will still pop up all at once. What you describe is true: Zope will not start sending the page until it is finished calculating. If one bit of your page takes a long time to calculate then the user will see *nothing* until that is complete. However, I don't think this limitation is affecting you. You say the page displays quickly when viewed over DSL - the connection bandwidth doesnt affect how long the page takes to calculate! A modem user will receive the first few bytes equally quickly - it just takes them longer the receive the rest. Toby Dickenson [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 )
[Zope-dev] Multi-homed objects?
Is there any reason why an object cannot be contained in more than one Folder in the ZODB? Apparently what I'm talking about is very similar to hard linking in UNIX... I can't think of any reasons why this would be bad but I can't think how to implement an 'Add hard link to this object' function... Ideas/comments? cheers, 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 )
[Zope-dev] Acquisition/cDocumentTemplate bug
Recently, several posters have reported strange "AttributeError __call__" exceptions. The most precise was a report by Oleg Broytmann: /index_html DTML Document dtml-var standard_html_header /standard_html_headerDTML Method dtml-with sub/dtml-with /sub Folder When he calls "/sub/index_html", he gets this "AttributeError __call__" for "sub". He observed the problem on Zope 2.1.4 and 2.2a4. I partially analysed this problem report under Zope 2.1.6: In "MM_cget", "sub" is retrieved as an "ImplicitAcquirerWrapper" (correct). In line 373, however, "PyCallable_Check(sub)" returned "1", which is probably wrong, because a folder is not callable. The "ImplicitAcquirerWrapper"'s "tp_call" mislead "PyCallable_Check". In line 376, the attribute "py_isDocTemp" is looked up and succeeds. Therefore, the folder "sub" is seen as a Document Template, which definitely is not true. The following call fails because it arrives at CallMethodO in "Acquisition.c:119" which looks for a non-excisting "__call__" method. 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] Multi-homed objects?
On Mon, 17 Jul 2000, Chris Withers wrote: Is there any reason why an object cannot be contained in more than one Folder in the ZODB? Apparently what I'm talking about is very similar to hard linking in UNIX... Hardlinks are prohibited on directories; and 5 minutes ago you said all objects are foldersih :) Hardlinks are prohibited on directories because it'd cause infinite loops on traversing. Oleg.(All opinions are mine and not of my employer) Oleg Broytmann Foundation for Effective Policies [EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] Multi-homed objects?
Oleg Broytmann wrote: Hardlinks are prohibited on directories; and 5 minutes ago you said all objects are foldersih :) I'm not sure if my statement applies in this situation... ;-) Hardlinks are prohibited on directories because it'd cause infinite loops on traversing. Hmm, would Python catch those already? Obviously care would need to be taken and it might be possible to build a loop checker into whatever creates the hard links... cheers, 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 )
[Zope-dev] ZPatterns: Coad Object Models
Hi Folks, After the ZPatterns chat on Friday, it looked like a few people were thinking of getting into Peter Coad's book "Object Models: Strategies, patterns and applications". I've just received my copy, and I'll be starting it later today. I intend to use a Wiki to record my observations and thoughts about the book, as I read it. I'd like this to be a collaborative learning thing, so anyone else who is reading the book, or who as read it, is most welcome to join in. http://www.zope.org/Members/stevea/CoadObjectModels There's not much up there right now, as I've only read the Acknowledgements at the front :-) -- 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] Multi-homed objects?
Chris Withers wrote: Oleg Broytmann wrote: Hardlinks are prohibited on directories; and 5 minutes ago you said all objects are foldersih :) I'm not sure if my statement applies in this situation... ;-) Hardlinks are prohibited on directories because it'd cause infinite loops on traversing. Hmm, would Python catch those already? Obviously care would need to be taken and it might be possible to build a loop checker into whatever creates the hard links... This could be part of a "visitor" interface I've been pondering in the back of my mind. It would be capable of traversing, performing an arbitrary function, and never falling into a recursive trap. class ObjectManager: ... def visit(self, func, visited=()): func(self) for id in self.objectIds(): ob = self._getOb(id) if hasattr(ob, 'visit') and ob not in visited: ob.visit(func, (ob,) + visited) 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] Wstring
On Mon, 17 Jul 2000 21:05:06 +0800, "Sin Hang Kin" [EMAIL PROTECTED] wrote: hello : Does anyone known how to patch Zope2.2 for Wstring? If you mean my wstring patches that were developed for 2.1.6, you will find some updated patches at the original location, www.zope.org/Members/htrd/wstring The current patch (version 0.3) is incompatible with the previous ones (but this time it 'feels right'. I plan to keep this interface stable). It needs python 2.0, and uses the new built-in unicode type. Toby Dickenson [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] Multi-homed objects?
On Mon, 17 Jul 2000, Chris Withers wrote: How does it work in Unix? (that seems to be a good baseline :-) On UNIX symlink is not a link - it is a text file, that contains a name of resource. The name could points to nowhere, or to resource, even to other symlink... Oleg.(All opinions are mine and not of my employer) Oleg Broytmann Foundation for Effective Policies [EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] Question: circumventing the full fishbowl for small changes...?
I've reviewed the introduction to the fishbowl process and its description of creating a project proposal wiki document and such, and the full process a project should take. However, I have 2 very small but useful additions to Zope I wish to make. Both additions are already available for download on zope.org - and have been tested extensively. However, the larger of the two changes is perhaps 80 lines of code. It seems cumbersome, to me at least, to go through this whole process of "Inception, Elaboration, Construction, and Transition" for small code snippets which are already created and tested... So, my question is, could a side-line process be created for the integration of already existent, tested, and somewhat small, code changes? snip Please keep in mind that I am not trying to be critical, nor am I attempting to change the fishbowl process for normal projects - I only wish a parallel process to exist for very small changes, so that the changes are not forgotten or passed up. Hi Jon - You are correct that we need something featherweight for very specific features/changes. I know that it's not optimal, but for right now the process for things like this is to add a feature request (preferably w/patch) to the collector. My hope is that some of the other things going on will allow us to be better about getting to those things. I expect to still try to get the community involved in those small decisions (voting, etc. on the dev list). Hopefully that will be good enough to hold us for a little while - I'm open to feedback on how we might improve this (though for the immediate near term I prefer to focus the bulk of effort on working out kinks in the process for larger projects). Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.com ___ 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] 2.2 annoying nit
Hi there, I see that the 2.2 still has this annoying, and seemingly completely unnecessary minor change in the tab order: Tabs for folder in 2.1: Contents View Properties Import/Export Security Undo Find Tabs for folder in 2.2: Contents Import/Export Properties View Find Security Undo Ownership What's the reason for this change? I'm rather used to the original configuration; I imagine other users are too. Why is everything reordered? I posted this to the collector 10 days ago, but the status is still 'pending' and 2.2 was released. While of course this is a minor thing, why make everyone relearn the interface? It's akin to switching 'file' and 'edit' around in a GUI. :) Regards, Martijn ___ 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] The Application object
I'm not sure I understand. What is AppSingleton? What does the Instance() method do? -Original Message- From: Jeff K. Hoffman [mailto:[EMAIL PROTECTED]] Sent: Monday, July 17, 2000 11:54 AM To: [EMAIL PROTECTED] Subject: [Zope-dev] The Application object Hello, What is the easiest way for me to get ahold of the Application object at run-time? I am writing a Product that needs to access some things in the Control_Panel, and need the app object to get there. I know how to do it given a reference to an object in the ZODB (getPhysicalRoot(), etc.), but need a way to do it given no references. I need something like: import AppSingleton app = AppSingleton.Instance() app.Control_Panel.blah --Jeff --- Jeff K. Hoffman 704.849.0731 x108 Chief Technology Officer mailto:[EMAIL PROTECTED] Going Virtual, L.L.C. http://www.goingv.com/ ___ 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 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] The Application object
On Mon, 17 Jul 2000, Chris McDonough wrote:
I'm not sure I understand. What is AppSingleton? What does the
Instance() method do?
Sorry I wasn't clear enough. The Singleton is a design pattern from the
Gang of Four book that fits this situation well. It is a class that is
meant to control access to the one and only instance of a global
variable. I was just using that as a frame of reference, though; Zope has
no such class for the Application object, or I wouldn't be writing this
message.
I just need some way of getting at the one and only Application object at
run-time. Something like:
from Globals import app
myOb = app.Control_Panel.Products.MyProduct.MyZClass('foo')
...
Given a reference to an object in the ZODB, I can do this via:
app = self.getPhysicalRoot()
myOb = app.Control_Panel.Products.MyProduct.MyZClass('foo')
But, this does not work from methods like __init__, or __setstate__, where
we do not have a physical location in the ZODB, yet.
I just need a reference to the app object. I know the answer has to be
simple, but I can't find it.
--Jeff
---
Jeff K. Hoffman 704.849.0731 x108
Chief Technology Officer mailto:[EMAIL PROTECTED]
Going Virtual, L.L.C. http://www.goingv.com/
___
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] The Application object
Sorry I wasn't clear enough. The Singleton is a design
pattern from the
Gang of Four book that fits this situation well. It is a
class that is
meant to control access to the one and only instance of a global
variable. I was just using that as a frame of reference,
though; Zope has
no such class for the Application object, or I wouldn't be
writing this
message.
Oh, ok, sorry, hard to tell intent from actual code. :-)
I just need some way of getting at the one and only
Application object at
run-time. Something like:
from Globals import app
myOb = app.Control_Panel.Products.MyProduct.MyZClass('foo')
...
Given a reference to an object in the ZODB, I can do this via:
app = self.getPhysicalRoot()
myOb = app.Control_Panel.Products.MyProduct.MyZClass('foo')
But, this does not work from methods like __init__, or
__setstate__, where
we do not have a physical location in the ZODB, yet.
Ah, I see the problem.
I'm afraid I don't know the answer.
I generally use the manage_afterAdd and manage_beforeDelete methods to
do things like this.
I suppose you could pass the root object into the constructor.
__setstate__... well. Err...
Anybody else?
___
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] The Application object
Chris McDonough wrote:
Sorry I wasn't clear enough. The Singleton is a design
pattern from the
Gang of Four book that fits this situation well. It is a
class that is
meant to control access to the one and only instance of a global
variable. I was just using that as a frame of reference,
though; Zope has
no such class for the Application object, or I wouldn't be
writing this
message.
Oh, ok, sorry, hard to tell intent from actual code. :-)
I just need some way of getting at the one and only
Application object at
run-time. Something like:
from Globals import app
myOb = app.Control_Panel.Products.MyProduct.MyZClass('foo')
...
Given a reference to an object in the ZODB, I can do this via:
app = self.getPhysicalRoot()
myOb = app.Control_Panel.Products.MyProduct.MyZClass('foo')
But, this does not work from methods like __init__, or
__setstate__, where
we do not have a physical location in the ZODB, yet.
Ah, I see the problem.
I'm afraid I don't know the answer.
I generally use the manage_afterAdd and manage_beforeDelete methods to
do things like this.
I suppose you could pass the root object into the constructor.
__setstate__... well. Err...
Anybody else?
The way to get the root application object is to open a connection to
the ZODB and get the 'Application' object from the list of root
objects. There is an easy shortcut:
import Zope
app = Zope.app()
app now refers to a *copy* of the root Application object. When you're
done modifying it and its descendants you have to commit or abort the
transaction.
get_transaction().commit() (or abort())
This gives you all kinds of benefits like undo and elimination of
threading conflicts. You *must* remember to close the connection:
app._p_jar.close()
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] The Application object
On Mon, 17 Jul 2000, Shane Hathaway wrote:
The way to get the root application object is to open a connection to
the ZODB and get the 'Application' object from the list of root
objects. There is an easy shortcut:
import Zope
app = Zope.app()
app now refers to a *copy* of the root Application object.
Yeehaw, that worked! I was so close. :-)
When you're done modifying it and its descendants you have to commit or
abort the transaction.
[snip]
Do I need to commit or abort even if I don't make changes to the
application object? The only thing I need it for is to get to the
Control_Panel; I am instantiating ZClass instances in the constructor of a
Python class, i.e.:
class MyClass:
def __init__(self, id, title=''):
import Zope
app = Zope.app()
ob = app.Control_Panel.Products.MyProduct.MyZClass('newId')
ob.id = 'newId'
self._setObject('newId', ob)
# Do I need a get_transaction().abort() here? Will that not abort
# the wrong transaction?
app._p_jar.close()
...
This gives you all kinds of benefits like undo and elimination of
threading conflicts.
[snip]
Good stuff. Thanks, Shane.
Shane
--Jeff
---
Jeff K. Hoffman 704.849.0731 x108
Chief Technology Officer mailto:[EMAIL PROTECTED]
Going Virtual, L.L.C. http://www.goingv.com/
___
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] The Application object
So it's kosher then to reimport the Zope module and use app() in a
constructor method, Shane? I was always afraid it would do something
horrible.
-Original Message-
From: Jeff K. Hoffman [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 17, 2000 1:11 PM
To: Shane Hathaway
Cc: Chris McDonough; 'Jeff K. Hoffman'; [EMAIL PROTECTED]
Subject: Re: [Zope-dev] The Application object
On Mon, 17 Jul 2000, Shane Hathaway wrote:
The way to get the root application object is to open a
connection to
the ZODB and get the 'Application' object from the list of root
objects. There is an easy shortcut:
import Zope
app = Zope.app()
app now refers to a *copy* of the root Application object.
Yeehaw, that worked! I was so close. :-)
When you're done modifying it and its descendants you have
to commit or
abort the transaction.
[snip]
Do I need to commit or abort even if I don't make changes to the
application object? The only thing I need it for is to get to the
Control_Panel; I am instantiating ZClass instances in the
constructor of a
Python class, i.e.:
class MyClass:
def __init__(self, id, title=''):
import Zope
app = Zope.app()
ob = app.Control_Panel.Products.MyProduct.MyZClass('newId')
ob.id = 'newId'
self._setObject('newId', ob)
# Do I need a get_transaction().abort() here? Will that
not abort
# the wrong transaction?
app._p_jar.close()
...
This gives you all kinds of benefits like undo and elimination of
threading conflicts.
[snip]
Good stuff. Thanks, Shane.
Shane
--Jeff
---
Jeff K. Hoffman 704.849.0731 x108
Chief Technology Officer
mailto:[EMAIL PROTECTED]
Going Virtual, L.L.C. http://www.goingv.com/
___
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] Errors causing half rendered pages
On Sun, Jul 16, 2000 at 10:38:41PM +0100, Chris Withers wrote: Dieter Maurer wrote: I saw this only when buggy HTML was generated. When I viewed the HTML source my Netscape browser sometimes showed me blinking parts that located the errors. Nope, this was with IE... I viewed source and sure enough, it ended after a few lines. I guess it might have something to dop with streaming HTTP output, but I don't think Zope uses that... Ideas anyone? THis rings vague bells of IIS or some other proxy server or somthing converting LF tp CRLF but not updating the Content-Length header, thus having your browser drop part of the transmission. I could be talking absolute nonsense of course. -- Martijn Pieters | Software Engineermailto:[EMAIL PROTECTED] | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ | ZopeStudio: http://www.zope.org/Products/ZopeStudio - ___ 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] The Application object
On Mon, Jul 17, 2000 at 12:21:42PM -0400, Jeff K. Hoffman wrote:
On Mon, 17 Jul 2000, Chris McDonough wrote:
I'm not sure I understand. What is AppSingleton? What does the
Instance() method do?
Sorry I wasn't clear enough. The Singleton is a design pattern from the
Gang of Four book that fits this situation well. It is a class that is
meant to control access to the one and only instance of a global
variable. I was just using that as a frame of reference, though; Zope has
no such class for the Application object, or I wouldn't be writing this
message.
I just need some way of getting at the one and only Application object at
run-time. Something like:
from Globals import app
myOb = app.Control_Panel.Products.MyProduct.MyZClass('foo')
...
Given a reference to an object in the ZODB, I can do this via:
app = self.getPhysicalRoot()
myOb = app.Control_Panel.Products.MyProduct.MyZClass('foo')
But, this does not work from methods like __init__, or __setstate__, where
we do not have a physical location in the ZODB, yet.
I just need a reference to the app object. I know the answer has to be
simple, but I can't find it.
See the __init__.py method of ZScheduler, which can be found on Zope.org.
ZScheduler uses a Singleton as well.
--
Martijn Pieters
| Software Engineermailto:[EMAIL PROTECTED]
| Digital Creations http://www.digicool.com/
| Creators of Zope http://www.zope.org/
| ZopeStudio: http://www.zope.org/Products/ZopeStudio
-
___
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] Multi-homed objects?
Terry Kerr wrote: Where would the object aquire its attributes from? Would it try one of its folders, then the other? Which order would it choose? Now that's a very good question ;-) Probably from the folder you referenced it from and then normal acquisition from then on... cheers, 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] The Application object
On Mon, 17 Jul 2000 12:50:27 -0400 Shane Hathaway [EMAIL PROTECTED] wrote: import Zope app = Zope.app() get_transaction().commit() I am doing just that in the next version of zzLocale (Zope interface internationalization product) I was about to release. I figured it out from the "Zope Debugging" doc (http://www.zope.org/Documentation/Misc/DEBUGGING.txt), but: You *must* remember to close the connection: app._p_jar.close() This is not mentionned in the above document, so I was doing without so far, and did not run into any problem. Now that I see it, I believe this is the Right Thing to Do and will include it in the release. But since you put an emphasis on its being required, can you tell us what evil things may happen if you don't close the connection? (Consuming ressources?) -- Yves-Eric Martin Digital Garage Inc. [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] CalendarTag fix for Zope 2.2
Shane already told me about this bug, the latest release (0.9.17) is fixed. Here is a small patch to make the lovely calendar tag play nice with DT_Util.namespace() in Zope 2.2: $ diff -c lib/python/Products/Calendar/CalendarTag.py \ lib/python/Products/Calendar/CalendarTag.py.org *** lib/python/Products/Calendar/CalendarTag.py Sun Jul 16 21:39:27 2000 --- lib/python/Products/Calendar/CalendarTag.py.org Sun Jul 16 21:41:40 2000 *** *** 248,254 __call__ = render def render_day_(self, md, date, firstday): ! ns = namespace(md, date = date, mode = self.mode, firstday = firstday, --- 248,254 __call__ = render def render_day_(self, md, date, firstday): ! ns = namespace(self, date = date, mode = self.mode, firstday = firstday, namespace() now insists that its self argument be an InstanceDict, which caused it to barf. -- = Tres Seaver [EMAIL PROTECTED] Digital Creations "Zope Dealers" http://www.zope.org ___ 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 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 )
