[Zope-dev] Using SQLTEST with Date
Hi, I cant use the SQLTEST tag with date variable in parameter to access an oracle database: When I use dtml-sqltest date type=string op=eq I have an Error. What sort of type can I use ?? In the Oracle database date is a date field. Thanks for your help
Re: [Zope-dev] Call Profiler
I've just announced our Call Profiler product on zope.org and the zope announce list (waiting for people in different timezones to authorise them :) ( http://www.zope.org/Members/richard/CallProfiler/ for the impatient) This is absolutely excellent, well done and thanks :) I added various FSObjects to the profiled modules list and have been looking at my CMF systems - it's really instructive. It does pose a question though: would it be better to have support for this stuff in the core, or is it OK for a product like this to dynamically patch the call methods when it needs to? I see nothing wrong with it being a monkeypatch product. On the other hand, it is a very useful tool, and as such could benefit from being in the core simply so that it always gets maintained with the core. On one hand, the performance hit when dynamically patching the methods is zero when the product is not active, but it does mean diddling with methods that really probably should be left alone. On the other hand, having changes to the core code to test for profiling being enabled introduces a small performance hit even when profiling is not activated. You could do this check only if zope is being run in debug mode; then there would be zero perormance hit in production sites. Any comments? I think the reporting could do with some usability improvements. It's good now, but takes a while to navigate round. - All the reports could benefit from being sortable by column. - the trace for a complete template could be slightly clearer. The colour coding for the start and end of a module could have a clear legend, for example. - there needs to be some solution for really long URLs, which require lots of horizontal scrolling - just displaying the final parts of the path, with the rest of the url hidden somehow? I can't think of exactly what else I would do to improve it right now, though. And that's the kind of change I never get round to bothering with, personally... Sorry these aren't really constructive ideas, but you did ask for feedback :-) seb ___ 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] Call Profiler
On 1/2/02 1:13 am, Richard Jones [EMAIL PROTECTED] wrote: I've just announced our Call Profiler product on zope.org and the zope announce list (waiting for people in different timezones to authorise them :) ( http://www.zope.org/Members/richard/CallProfiler/ for the impatient) [snip] Any comments? I've been using it for *5* minutes and have found a method that was taking 95%! of one of our most often used scripts and another python script that was effectively stalling the servergobsmacked. Huge kudos and thanks to Richard!! :) Tone. -- Dr Tony McDonald, Assistant Director, FMCC, http://www.fmcc.org.uk/ The Medical School, Newcastle University Tel: +44 191 243 6140 A Zope list for UK HE/FE http://www.fmcc.org.uk/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 )
[Zope-dev] Generating abstracts in ZCatalog
Hi, I'm quite new to all this Zope development but seem to be picking things up quite nicely. However, I am having a problem generating abstracts for my Search Engine. It's something that I used to be able to do quite easily in IIS / ASP but being new to Zope I can't seem to find a way how to do it automatically. Firstly, is this possible within Zope? And if so, how? Thanks in advance, and apologies if there is an obvious answer to this that I've missed (even though I did painstakingly search through the archives!) ___ 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] Dynpersist.so and makefile.pre.in
On Thu, 31 Jan 2002, Jeffrey P Shell wrote: On 1/31/02 5:02 PM, Ed Colmar [EMAIL PROTECTED] wrote: Are there any other (simple) solutions to doing authentication through a SQL DB? Jumping through hoops to get Zpatterns working seems silly when all I need is basic authentication. Though it would probably make my life easier once I figure it out. You might want to check out http://www.zope.org/Members/otto/userdb, although it looks rather old. If it's what I think it is, it's based on You might also want to check out http://www.zope.org/Members/TheJester/exUserFolder --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] Call Profiler
Doesnt seem to like being refreshed and some event items arent in the time dict, I noticed these were items that I had got in a ram cache. So i just stuck an if at line 496. Other than that its a great product. Most important tool since refresh if you ask me... - Original Message - From: Richard Jones [EMAIL PROTECTED] To: zope-dev [EMAIL PROTECTED] Sent: Thursday, January 31, 2002 5:13 PM Subject: [Zope-dev] Call Profiler I've just announced our Call Profiler product on zope.org and the zope announce list (waiting for people in different timezones to authorise them :) ( http://www.zope.org/Members/richard/CallProfiler/ for the impatient) In a nutshell, it patches the rendering guts of DTMLMethod, ZSQL, etc. and the ZPublisher so that we can get timing marks for requests as the calls are made. The patching is quite simple (once I got the hang of it ;) and reversible, and means that there's no changes required to the Zope core to enable the testing (which our initial versions did). It does pose a question though: would it be better to have support for this stuff in the core, or is it OK for a product like this to dynamically patch the call methods when it needs to? On one hand, the performance hit when dynamically patching the methods is zero when the product is not active, but it does mean diddling with methods that really probably should be left alone. On the other hand, having changes to the core code to test for profiling being enabled introduces a small performance hit even when profiling is not activated. Any comments? Richard ___ 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] Generating abstracts in ZCatalog
On Fri, 1 Feb 2002, Cuthbertson, Mark wrote: Hi, I'm quite new to all this Zope development but seem to be picking things up quite nicely. However, I am having a problem generating abstracts for my Search Engine. It's something that I used to be able Probably you should post to [EMAIL PROTECTED] rather than here, as this is a question about using zope, not developing code for it. I'm not sure what you mean by abstracts for my search engine, but the metadata feature of the ZCatalog would seem to be a logical candidate. --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 )
[Zope-dev] Zope 2.5. cAccessControl.c tentative patch
FYI, those people who had to set ZOPE_SECURITY_POLICY to PYTHON are advised to apply the following Patch for 2.5's cAccessControl.c module and see if it helps. As far as I can see, it solves the Zope 2.5 problems reported by Martijn Faassen with ParsedXML. -- Matt Kromer Zope Corporation http://www.zope.com/ Index: cAccessControl.c === RCS file: /cvs-repository/Zope/lib/python/AccessControl/cAccessControl.c,v retrieving revision 1.13 diff -u -r1.13 cAccessControl.c --- cAccessControl.c11 Jan 2002 17:14:27 - 1.13 +++ cAccessControl.c1 Feb 2002 17:27:31 - @@ -1703,6 +1703,7 @@ Py_DECREF(r); r = self-__roles__; if (r == NULL) goto err; + Py_INCREF(r); } /*|
Re: [Zope-dev] Re: [Zope-CMF] How to get Type in manage_afterAdd?
Florent Guillaume writes: Anyway I'd propose the following: we need, in constructInstance, to somehow pass the portal_type to the object constructor. Unfortunately this has to be backwards-compatible with all the constructors out there that don't know about it. I see two possible ugly solutions to do it: - do constructor.__portal_type = portal_type before calling constructor(...), and the constructor does something like: def manage_addFoo(...): try: portal_type = manage_addFoo.__portal_type manage_addFoo.__portal_type = None except: portal_type = None Usually, this dynamic modification is not a good idea in a multi-threaded environment. If constructor is (part of) a persistent object, it might work in Zope but may entail unnecessary writes to the ZODB. 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] self = self.this() in Factory Methods [Was: Dynpersist.so andmakefile.pre.in]
At 01.02.2002 10:44 -0500, R. David Murray wrote: You might also want to check out http://www.zope.org/Members/TheJester/exUserFolder --RDM All, Please have a look at my patch for XUF at http://www.zope.org/Members/shh/Patches/exUserFolder-0.10.4.patch I believe that manage_addexUserFolder() is faulty, in that it does not call the FactoryDispatcher's this() before assigning to self.__allow_groups__. My point is that 'self' is initially referring to a FactoryDispatcher (App/FactoryDispatcher.py) which does *not* define __setattr__(). I believe this to be the reason for issues surrounding XUF like undeletable userfolders where the __allow_groups__ attribute appears to be installed in the wrong place. Please give this a sanity check, so that either I can take down the patch or the XUF maintainers can fix their product. I am CC-ing AKM on this as I have regrettably lost our correspondence and only remember that my patch had been rejected for some reason ;-) Thanks, Stefan -- I am not posting to the XUF list as I would have to subscribe first. ___ 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] Re: self = self.this() in Factory Methods [Was: Dynpersist.so and makefile.pre.in]
+---[ Stefan H. Holek ]-- | At 01.02.2002 10:44 -0500, R. David Murray wrote: | | All, | | Please have a look at my patch for XUF at | http://www.zope.org/Members/shh/Patches/exUserFolder-0.10.4.patch | | I believe that manage_addexUserFolder() is faulty, in that it does not call | the FactoryDispatcher's this() before assigning to self.__allow_groups__. | | My point is that 'self' is initially referring to a FactoryDispatcher | (App/FactoryDispatcher.py) which does *not* define __setattr__(). As I explained previously I think that if you are trying to install XUF (or anything) programmatically from a ZClass, then you should call the manage_addFoo() on an instanciated object i.e. a Folder or some other container that your ZClass has created, not on your Dispatcher. If someone gives me a sane reason why this isn't correct and that calling self = self.this() in every product constructor is actually the correct behaviour I'll put it in (as opposed to catering for lazy ZClass programmers d8) Not that this seems to be in very many constructors for Zope stuff or other products I have installed. Since it seems this is going to occur repeatedly, having spent 10 seconds looking at it, it seems that the 'correct' way is to call self.Destination()._setObject() so in essence self.Destination().__allow_groups__ will also get what we want. This is actually documented (although it's not clear what versions of Zope this will work with, or whether this will do the same thing as self._setObject(), it's late, I've had no sleep, I'll look later, or someone who actually knows can fill in the blanks for us, but, I think it's 2.4 only) It doesn't seem to be used by any of the Zope objects in 2.4.3 (at least not in any python ones), so it's hard to say. The ZDG does not say that self (or dispatcher as it says), will not be usable as if it was your ObjectManager. The add function will be passed a FactoryDispatcher as its first argument which proxies the location (usually a Folder) where your product was added. This implies nothing special is needed to use the first argument as if it was the ObjectManager to which you are being installed. So from this it seems if you are running 2.4 that self should be a proxy to an ObjectManager to which you can add things w/o calling Destination() | I believe this to be the reason for issues surrounding XUF like | undeletable userfolders where the __allow_groups__ attribute appears to | be installed in the wrong place. err no. That was something completely unrelated, and had to do with the manage_beforeDelete() failing (now corrected). | I am not posting to the XUF list as I would have to subscribe first. Yes, we enjoy the lower spam count over on -devel, -users is open though. If you want to discuss XUF devel issues then you should subscribe and you should post there. Your patch was rejected because it claimed to fix something it was unrelated to, namely the __allow_groups__ persisting after the acl_users was deleted. Your fix could not have possibly fixed it, because the code that actually removed the attribute was never executed, which means you didn't actually test your patch against the condition you told me it was supposed to fix. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[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 )
