Re: [Zope-CMF] Re: pdf generation
Philipp von Weitershausen wrote: Charlie Clark wrote: Do you know of a Zope Product that already wraps report lab, or do you recommend just accessing directly with a script? I can't think of anything that would do this for you: transforming HTML to PDF doesn't usually work very well. Reportlab is fairly easy to use and extremely fast. Except that it's apparently not thread-safe and should therefore be handled with care. A BFL has always solved any paranoid fears I've had in this area ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Making TypesTool faster
Alexander Limi wrote: This issue goes back to the original discovery that Zope had a bug that made its Product lookup mechanism What do you mean by Product lookup mechanism? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] memberdata + mysql integration
Miles wrote: - PAS: looks the most pluggable but doesn't seem to have a MySQL plugin and is quite complicated at first glance. - MySQLUserFolder: appears to fit the bill for authentication but no changes since late 2005. - ExUserFolder: also looks like it will deal with authentication but no changes since early 2005. You might want to have a look at SimpleUserFolder: http://www.simplistix.co.uk/software/zope/simpleuserfolder It allows arbitrary user properties and you can just write a ZSQL method to get what you need from MySQL. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF-checkins] SVN: CMF/trunk/CMFDefault/formlib/schema. - added Pdata support
PData is there for a reason, unravelling it into a string is often not
the best thing to do.
That said, I can't see much context here, but just thought I'd mention it..
Chris
Yvo Schubbe wrote:
Log message for revision 72567:
- added Pdata support
Changed:
U CMF/trunk/CMFDefault/formlib/schema.py
U CMF/trunk/CMFDefault/formlib/schema.txt
-=-
Modified: CMF/trunk/CMFDefault/formlib/schema.py
===
--- CMF/trunk/CMFDefault/formlib/schema.py 2007-02-14 03:44:40 UTC (rev
72566)
+++ CMF/trunk/CMFDefault/formlib/schema.py 2007-02-14 12:19:25 UTC (rev
72567)
@@ -18,6 +18,7 @@
from datetime import datetime
from DateTime.DateTime import DateTime
+from OFS.Image import Pdata
from zope.datetime import parseDatetimetz
from zope.interface import implements
from zope.schema import BytesLine
@@ -62,14 +63,18 @@
attribute = getattr(field, 'default', _marker)
if attribute is _marker:
raise AttributeError(self._field.__name__)
+elif isinstance(attribute, Pdata):
+attribute = str(attribute)
elif callable(attribute):
attribute = attribute()
+if self._field._type == str:
+return attribute
if isinstance(attribute, str) and inst.encoding:
return attribute.decode(inst.encoding)
-elif isinstance(attribute, DateTime):
+if isinstance(attribute, DateTime):
return parseDatetimetz(attribute.ISO8601())
-elif isinstance(attribute, (tuple, list)):
+if isinstance(attribute, (tuple, list)):
if inst.encoding:
attribute = [ isinstance(v, str)
and v.decode(inst.encoding) or v
Modified: CMF/trunk/CMFDefault/formlib/schema.txt
===
--- CMF/trunk/CMFDefault/formlib/schema.txt 2007-02-14 03:44:40 UTC (rev
72566)
+++ CMF/trunk/CMFDefault/formlib/schema.txt 2007-02-14 12:19:25 UTC (rev
72567)
@@ -9,6 +9,7 @@
class FooContent(PropertyManager):
... _properties=({'id':'foo_prop', 'type': 'string'},)
... foo_text = ''
+ ... foo_bytes = ''
... foo_datetime = None
... foo_set = ()
... foo_list = []
@@ -19,6 +20,7 @@
from zope import schema
class IFooContentView(Interface):
... foo_text = schema.Text()
+ ... foo_bytes = schema.Bytes()
... foo_datetime = schema.Datetime()
... foo_set = schema.Set()
... foo_list = schema.List()
@@ -29,6 +31,7 @@
class FooContentAdapter(object):
...
... foo_text = ProxyFieldProperty(IFooContentView['foo_text'])
+ ... foo_bytes = ProxyFieldProperty(IFooContentView['foo_bytes'])
... foo_datetime =
ProxyFieldProperty(IFooContentView['foo_datetime'])
... foo_set = ProxyFieldProperty(IFooContentView['foo_set'])
... foo_list = ProxyFieldProperty(IFooContentView['foo_list'])
@@ -51,6 +54,18 @@
adapter.foo_text == foo_text
True
+Pdata is read as str::
+
+ from OFS.Image import Pdata
+ foo_bytes = 'foo'
+ content.foo_bytes = Pdata(foo_bytes)
+ isinstance(content.foo_bytes, Pdata)
+ True
+ isinstance(adapter.foo_bytes, Pdata)
+ False
+ adapter.foo_bytes == foo_bytes
+ True
+
datetime is mapped to DateTime::
from datetime import datetime
___
CMF-checkins mailing list
CMF-checkins@zope.org
http://mail.zope.org/mailman/listinfo/cmf-checkins
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Zope 3 events from workflow
Martin Aspeli wrote: To subscribe only to particular transitions, you would need for each transition object to provide a specific interface. Unless you could leverage the same kind of thing that makes named adapters work... zope.event?), it registers a general subscriber for IObjectEvent and then redispatches for multi-subscribers based on (obj, event), i.e. you register a handler for the object type and for the event type. I actually don't like this pattern, it seems needlessly inefficient. Why not just set the right damned event going from the start? ;-) We could do the same for a transition event, e.g. re-dispatching based on object type, workflow type and/or transition type. Sounds like it would fit the idiom, even if I don't like it... However, in DCWorkflow, transitions are all of the same type, just with different ids, and in WorkflowTool, actions (of which DCWorkflow transitions are one common type) are also identified by a string only. See my comment about named thingies above, although this is largely hand waving on my part... It would be possible to define some kind of re-dispatch that used named adapters, but even though subscribers are just adapter factories under the hood (you'll see the slightly odd syntax of a loop that just retrieves all possible adapters from the component registry, doing nothing with the return values, because the event subscriber registry is using the same mechanism as the adapter factory registry, but the factory that is called normally does the event work), I don't think there's any natural syntax for registering named subscribers. You *could* do this though: @zope.component.adapter(Interface, IWorkflowTransitionEvent) def dispatch_transitions(obj, event): transition = event.transition.id factory = getMultiAdapter((obj, event), provides=INamedTransitionSubscriber, name=transition) subscriber handler=.dispatch.dispatch_transitions / - which would be generic and only be needed once. and then for each transition: @zope.component.implementer(INamedTransitionSubscriber) @zope.component.adapter(IMyObject, IWorkflowTransitionEvent) def react_to_published(obj, event): ... and in ZCML: adapter factory=.subscribers.react_to_published name=publish / I'm not sure this is any easier or less hacky than doing the subscriber like: @zope.component.adapter(Interface, IWorkflowTransitionEvent) def dispatch_transitions(obj, event): transition = event.transition.id if transition == 'publish': ... Yeah, decorators suck when abused and zcml just sucks ;-) *sigh* Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Zope 3 events from workflow
Hi All, Martin Aspeli wrote: class IWorkflowEvent(IObjectEvent): A workflow related event wf_name = TextLine(title=uThe name of the workflow this event is part of) transition = TextLine(title=uThe name of the transition taking place) state_before = TextLine(title=uThe object's state before the transition) state_after = TextLine(title=uThe object's state after the transition) I know I'm very late on this (sorry for taking a christmas vacation ;-) but how would I go about subcribing to a particular transition of a particular workflow? This feels like the most common case for me, but it would seem that if you want to do that with the current patch, you'd have to have a generic subscriber that then if/then/else'd its way to only doing the right thing for the right workflow and the right transition. I thought avoiding that kind of if/then/else'ing was what event subscribers were all about. Hopefully I'm just missing something, could someone enlighten me? (and by enlighten, I don't mean anything involving automotive fuel and matches :-P) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] [dev] writing tests for CMF 2.1
Hi All, yuppie wrote: Layers -- ZCML is set up using test layers. Their setUp() and tearDown() methods are only run once for all tests in the layer. Maybe of interest, I've attached the layers file I use when testing Zope 2 apps. It does the right thing w.r.t. having a DemoStorage for each layer, letting you safely commit transactions containing layer setup and then using the using transaction.begin()/transaction.abort() dance in the tests themselves. Is this code useful? Should I look to check it in to the core anywhere? For functional tests that depend on a complete CMF site, you can use the FunctionalLayers defined in the testing modules. They have to be used with ZopeTestCase's FunctionalTestCase Hmmm, which version of Zope did this arrive in? Finally, a question of my own, how do you use layers with doctests? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk import Globals import logging import transaction import Zope2 from AccessControl.SecurityManagement import newSecurityManager from AccessControl.SecurityManagement import noSecurityManager # this import, rather evilly, causes Zope2.bobo_application and Zope2.DB # to come into existence :-( from Testing.ZopeTestCase import ZopeLite from Testing.ZopeTestCase.utils import makerequest from ZODB import DB from ZODB.DemoStorage import DemoStorage state = [Zope2.DB] def setChickens(db): # Zope 2 chickens Globals.BobobaseName = db.getName() Globals.DB = db Zope2.DB = db Globals.UndoManager=db ZopeLite.DB = db junk_db, name, version_support = Zope2.bobo_application._stuff Zope2.bobo_application._stuff = db, name, version_support def addDB(): global state previous = state[-1] storage = DemoStorage(base=previous._storage) db = DB(storage) # cluck db.classFactory = previous.classFactory # cluck cluck setChickens(db) state.append(db) def removeDB(): global state db = state.pop() db.close() # un-cluck setChickens(state[-1]) class Layer1: @classmethod def setUp(cls): addDB() # etc # commit changes transaction.commit() @classmethod def tearDown(cls): # etc noSecurityManager() removeDB() ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: SVN: CMF/branches/1.6/ Avoid deprecation warnings with Zope 2.10.
Jens Vagelpohl wrote: I'd love to nail this one, it gets boring seeing it in a project's nightly test runs every night... A bit of grepping might find that one. :) Cool, lemme know when you're done :-P Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: SVN: CMF/branches/1.6/ Avoid deprecation warnings with Zope 2.10.
Jens Vagelpohl wrote: 2006-06-09 20:43:01 WARNING ZODB.DB DB.open() has 13 open connections with a pool_size of 7 Looks like someone somewhere ain't closing their zodb connection in a test... ERROR:foo.bar:eek None 2006-06-09 20:44:24 ERROR foo.bar eek None INFO:foo.bar:blah blah I'd love to nail this one, it gets boring seeing it in a project's nightly test runs every night... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CMF roadmap update
Tres Seaver wrote: Customization is hard: without TTW modules we *can't* do customization of arbitrary view logic. What's the blocker on this? Same thing that's blocking TTW schemas? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CMF roadmap update
Jens Vagelpohl wrote: I sent an email about this a couple days ago. Basically, I'm down to one failing unit test in CMFUid and have discovered that CMFUid is basically broken in 2.0/trunk. I also sent an email on this issue to the list, hoping that the developers who wrote CMFUid and lobbied hard to get it included would take notice and do something about it (or at least acknowledge it), but all I see is silence so far. At least I have found what the problem with CMFUid is, and it is mostly a misunderstanding how it is supposed to work. Mea culpa. I'm still left with the one failing unit test on the events branch, though. Having such an unknown and unmaintained piece of code in the core of the cmf scares me. How would people feel about deprecating it for 2.1 and removing it in 2.3 if no-one steps up who wants it? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope3-dev] Re: [Zope-CMF] Fighting the Zope 2.9 testrunner
Stuart Bishop wrote: silence it (and open a bug report at the same time). The noisier test output is, the more likely you are to miss relevant information. Totally agreed, I was kinda shocked at how many deprecation errors Zope 2.9 ships with :-( Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope3-dev] Re: [Zope-CMF] Fighting the Zope 2.9 testrunner
Stephan Richter wrote: On Tuesday 21 March 2006 02:54, Chris Withers wrote: I particularly hate the fact that no real effort was put into backwards compatibility, not to mention those silly weird sort-of-fifty-dots-per-line thing that doesn't actually work. I think this is not fair. Jim has tried very, very hard to convert all the functionality in a backward-compatible way. ...except one of the most commonly used parameters ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope3-dev] Re: [Zope-CMF] Fighting the Zope 2.9 testrunner
Philipp von Weitershausen wrote: Tres Seaver wrote: I'm not sure what Chris meant, but the change to the visual output of the testrunner when running with dots seems gratuitous to me, as well -- I don't see any benefit to the indented, narrower output, Me neither, for what it's worth. Okay, Tres, can you give me a line number I can poke at to remove this? It seems like Jim doesn't care too much, and I see 3 people at least who don't like it. Zope 2.9 broke the 'confiugre-make' dance in several ways, due (I think) to the choice to bolt on^H^H^H^H^H^H^Hretrofit zpkg. Sort of. It didn't break configure make. It's just make install that was broken. I think Tres was assuming that was an integral part of it ;-) I still don't understand why people whine about make install being gone. The point of a checkout is that you have a full functional SVN working copy, not an installation source. If you want to install things, use a TGZ archive which lets you do make install perfectly fine. I've never installed Zope anywhere except on production servers anyway, and there you should obviously use releases. Tres and Jens have already made the comments I was going to, but just to note that I strongly agree with them... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope3-dev] Re: [Zope-CMF] Fighting the Zope 2.9 testrunner
Jim Fulton wrote:
From the old testrunner, which I miss *a lot*, I could ensure I am
indeed running a specific module by doing...
Yup, this is one of the things I like least from the Zope 3 world.
What happened to proposals and community agreement before inflicting
big changes on other people who're trying to help out?
Oh cut the crap.
Hmm, I'm confused by this. If there's a proposal, my bad, point me at
it. If there isn't, well, it's kinda odd to receive abuse for pointing
out that you aren't sticking to your own processes...
The new test runner tries very hard to be backward
compatible.
...but misses one of the most common use cases from the old one, and you
didn't seem particularly fussed about fixing this :-S
This breakage was not intentional. It was a bug. There is an
easy work around: just use the -m option.
It can't be that hard to put in some syntactic sugar to support this. I
was going to give it a shot myself but I ran out of time, and I worry
about things like the regex matching the old testrunner used to dowhen
using the missing option.
I particularly hate the fact that no real effort was put into
backwards compatibility, not to mention those silly weird
sort-of-fifty-dots-per-line thing that doesn't actually work.
What the heck are you talking about? What doesn't work?
Here's a literal screen dump:
C:\Zope\2.9iC:\Zope\2.9.1\bin\python.exe C:\Zope\2.9.1\bin\test.py
--config-file C:\Zope\2.9i\etc\zope.conf --keepbytecode
Parsing C:\Zope\2.9i\etc\zope.conf
Running tests at level 1
Running unit tests:
Running:
.C:\Zope\2.9.1\lib\python\OFS\Application.py:598:DeprecationWarning:
The zLOG package is deprecated and will be removed in Zope 2.11. Use the
Python logging module instead.
('New disk product detected, determining if we need '
.
.
Ran 63 tests with 0 failures and 0 errors in 6.009 seconds.
C:\Zope\2.9i
It looks bizarre having that carriage return in the middle of the row of
dots. What's the point of the change that Tres added his patch to avoid
seeing?
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Fighting the Zope 2.9 testrunner
Jens Vagelpohl wrote: From the old testrunner, which I miss *a lot*, I could ensure I am indeed running a specific module by doing... Yup, this is one of the things I like least from the Zope 3 world. What happened to proposals and community agreement before inflicting big changes on other people who're trying to help out? I particularly hate the fact that no real effort was put into backwards compatibility, not to mention those silly weird sort-of-fifty-dots-per-line thing that doesn't actually work. My other big bug bear is what I've read about make-make-install no longer working in 2.9. Why on earth was this just broken without any thought to the vast number of people who rely on this as a simple way to quickly get a new release onto a number of boxes? I've been very happy to see the majority of the stuff in Zope 3, but it seems some things like this are getting rushed through without a lot of thought and consideration, which seems very un-zope-3 to me :-( Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Zope Debugger 0.8.2 Released!
Zope Debugger is an enhanced version of pdb for use with Zope. This release fixes compatability issues with Zope 2.9 and Python 2.4. It can be used simply by inserting the following lines in any python code you'd like to debug, including Script (Python)'s and FSPythonScripts: from Products.zdb import set_trace set_trace() It requires no changes to Zope, CMF or Plone or any funky interaction with any specific kind of editing software. All you really need to do is insert the snippet above and make sure your Zope instance is running in foreground mode. For more information, please see: http://www.simplistix.co.uk/software/zope/zdb cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Classes whose instances appear in ZODB
Lennart Regebro wrote: Nope, that's not equivalent. I'm not exactly sure what the requirements are. A getId method, a title attribute and a meta_type probably. Subclassing from SimpleItem is definitely a good idea. ...appart from the lame-ass allow by default security policy it drags in along the way :-/ Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] What's the story for using Z3 content types as first-class citizens in CMF?
Martin Aspeli wrote: Alec Mitchell's plone_schemas product lets you use such types in Plone, though he derives from CMF's PortalContent (as I recall) and manually constructs an FTI. FWIW, I think this is an exceptionally bad idea. I'd much prefer to see CMF grow a way to use Z3 content types without having to drag them down into the mire that is portal_types and the actions system :-S Maybe some kind of parallel thing where the UI-level stuff amalgamates both the CMF and Z3 ways of doing things (portal_types/content types and actions/menus) with the aim being eventually to drop the old CMF stuff? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] [dev] i18n Message objects: encoding issues
yuppie wrote: 2.) Switch completely to unicode in CMF 2.0: Sounds like a too big change, don't think we should try that. I think we all know this is where we need to be eventually, 2.0 seems the right time to do that, I'd actually prefer this, even though it'll delay the 2.0 release... 3.) Use encoded strings and unicode side by side: This requires to know the encoding of the encoded strings. 'default_charset' should provide that information. arrrgg there be dragons... 3.1.) Encode unicode strings before passing them to page templates: The unicode strings are only returned by newly added parts of the code. So it might be easier to find all the places where a conversion is necessary. On the other hand Message objects are also unicode, so we would have to translate them before passing them to the templates. Yeah, okay, it'll work, but it sucks long term as it's even mroe code that needs to be undone when CMF goes fully unicode... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CMF GenericSetup log levels
yuppie wrote: 1.) It would be nice to have a policy for Zope. If the Zope core officially supports the BLATHER level (not just in the deprecated zLOG module) I'm fine with using it in GenericSetup as well. It doesn't, ZODB has a mapping for it but it's a stupid name left over from before the same timeframe as STUPID_LOGGER and some of the wacky error messages that ZServer used to spit out. I really want it to die :-( Python has .info and .debug. If this stuff is useful and normal people will want to know it, it should be at info. If it's not really that interesting and is only useful when there's a problem, it should be at .debug 2.) So far IWriteLogger just defines methods that are also used by the python logging Logger. If we add a blather method we can no longer use the python logger as a replacement. Hmmm, this sounds odd. Why does IWriteLogger even exist if it just mirrors the python logging interface? 3.) I don't think all messages should have the same logging level. E.g. if there are problems that will cause broken setups WARNING might be appropriate. No, .error is what you want here. .warning is for things that are problems but which don't result in broken setups. Messages that report the success of export steps are a candidate for DEBUG. Agreed, although a summary logged at info at the end would be nice... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF GenericSetup log levels
yuppie wrote: By 'broken setups' I meant e.g. if you loose some catalog indexes on export/import because no handler exists for those index classes. This is a problem you should know about, but maybe you don't care or you fix that by hand. Ah, okay, I kinda agree here, and don't feel strongly enough about it to argue :-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF GenericSetup log levels
Hi Tres, Tres Seaver wrote: No, it isn't, at least in Zope. BLATHER is intended to be summary information, useful for developers but not important enough to show by default. DEBUG is for more detailed information, and TRACE is for completely overwhelming detail. Show me the docs in zope and I'll believe that's not just your interpretation ;-) Sure it is ;-) You seem to be confusign .info with .warning. If your funny customers get scared by stuff at .info, then change their log level in zope.conf to warning, then they won't bug you so much and in turn get you bugging the rest of us to log at the wrong levels ;-) Your misunderstanding of Zope's levels is clearly present in that sentence, Chris. Oh? Please explain... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: SVN: CMF/trunk/ - converted types tool setup handlers to new style
Florent Guillaume wrote: Or even better: self._logger.info(%r type info imported. % self.context.getId()) Or you could even take advantage of the good work done by the python logging people ;) self._logger.info(%r type info imported.,self.context.getId()) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: reindexing optimizations
Julien Anguenot wrote: Can you gimme a use case, within a test, where the interface we define in CPS would not be enough for you ? In our CPSTestCase we set all subscribers to 'async' and then all works as if no txn subscribers exists during the tests. Ah, okay, yes, I guess this is one way to do it. Also, how would you go about overriding this late-indexing behaviour if you really wanted to for some specific objects? Define reindexObject() and reindexObjectSecurity() on the given content type for instance. But clearly, we could think about a more complex Transaction Manager that may deal with more complex use cases such as this one. We didn't express this need yet. Yep. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] reindexing optimizations
Hi Alec, Alec Mitchell wrote: So, Sidnei has been plugging away at the AT reindexes things an obscene number of times issue today, and appears to have fixed many of the AT triggered indexing redundancies. Where is this work being done? I'd be very interested to track it... *) TypesTool.constructInstance() is triggered **) A _setObject call results in CMFCatalogAware.manage_afterAdd() which triggers a full indexObject(). So this one should go away some how :-S *) This is shortly followed by TypesTool._finishConstruction() *) Which calls CMFCatalogAware.notifyWorkflowCreated() *) Which in turn calls WorkFlowTool._reindexWorkflowVariables() **) Which does a CMFCatalogAware.reindexObject([idxs]) on workflow specific variables (with a full metadata update) And this one too? *) And calls CMFCatalogAware.reindexObjectSecurity() which reindexes the object only on the security index, and doesn't touch metadata. Does reindexObjectSecurity do anything other than just the reindex the security indexes? If not, it can go too ;-) **) TypesTool._finishConstruction() then does another CMFCatalogAware.reindexObject(). ...leaving just this one :-) So we have two full reindexes, and three metadata updates. The last reindex appears to be there only to catch the change to 'portal_type' in _finishConstruction. Well, it's the last one, so I'd argue it should be the _only_ one. Why do things need to be indexed before then? Additionally, almost immediately before this last reindexObject call, another reindexObject call has happened in notifyWorkflowCreated, which included a full catalog metadata update. As a result, updating the catalog metadata here is certainly redundant. Unfortunately, the CMFCatalogAware.reindexObject method provides no means of avoiding the duplicate metadata update, though it would be trivial to add and to use here. That sounds like a good idea :-) Another option suggested by Sidnei on IRC, which would avoid the potential issues with limiting the variables indexed in the final reindex. Would be to let CMFCatalogAware.manage_afterAdd know (presumably via some state variable) Why a state variable rather than just a parameter? that it is being invoked through constructInstance/invokeFactory, in which case it could safely skip the initial indexing and allow _finishConstruction to take care of indexing the object fully on it's own at the end. +1 from me. In the long term we will probably be better served by delaying all indexing to transaction boundaries, though it will be a fair bit harder to implement, and may irk some developers who depend on immediate changes to the catalog on reindex. Yeah, it also makes things harder to test. Unit tests require stuff to be indexed, so if this was the way to go, which apart from that one thing I think _should_ be the case, there should be a flush all pending indexing thing, which should keep everyone happy. Just have to make sure that then doesn't get misused and end up being called 100 times per operation ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: reindexing optimizations
Florent Guillaume wrote: That's certainly a good hack. There are several ways to do it, either with a thread-local variable, or in the request, or by walking the stack's locals to check for a __dont_index__ attribute... You'd have to bench, but a thread-local variable is probably the fastest. You want to store a set of objects whose indexing should be skipped. Urm? Surely it's the other way round? ie: you build a mapping of objects that need re-indexing, so you only re-index each one once... As Julien said it's not very hard to implement, it's just that there are application changes to consider. Still, there's agreement that CMF should move in that direction, I can provide patches taken from the CPS implementation. (And it requires Zope 2.8/ZODB 3.4 of course.) Some of the framework should pushed into Zope itself. I think this is the way to go, but I do feel there should be some override method for unit testing and als ofor where you want to do a search after doing a load of object changes cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: reindexing optimizations
Julien Anguenot wrote: yup you're right. We do define this already. All the subscribers can run 'async' or 'sync' . Check the base interface for those subscribers there : http://svn.nuxeo.org/trac/pub/file/CPSCore/trunk/interfaces.py http://svn.nuxeo.org/trac/pub/file/CPSCore/trunk/BaseManager.py Not quite the semantics I had in mind, I meant more of a flush-type method... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: reindexing optimizations
Julien Anguenot wrote: If you want a flush, following what I think I understood you mean ;), we use the transaction.commit() in the tests when needed. Okay, but then how do you undo the changes made by that commit? Also, how would you go about overriding this late-indexing behaviour if you really wanted to for some specific objects? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Catching logging during unittesting?
Hi All, Asking here 'cos I'm sure I saw someone talking about this recently. I'm unit testing something which does some logging. It's supposed to log, so ideally I'd like to test for that, but I'd also like to not have the log spew showing during tests runs, which seems to have started happening in Zope 2.8 :-S I tried using the LogInterceptor mixin, but that only works for zLOG, whereas I'm using what we should all be using: the new python logging module. Any ideas? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] CMF 1.6
Alec Mitchell wrote: to start using it immediately or risk strange breakages. Maintaining product compatibility between versions of CMF/Plone will become nearly impossible. I'm sorry, I really couldn't resist this... And that differs from other Plone releases how exactly? ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [dev] RFC: logging/reporting framework for GenericSetup
yuppie wrote: Or would be 'GenericSetup.content' enough? Yes, that looks nicer to me :-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6
Alexander Limi wrote: And that differs from other Plone releases how exactly? ;-) And what, exactly, have you done to help Plone have less bugs? *sigh* there's not a lot I can do, the problems with Plone are cultural. There seems to be a pervasive culture of monkey patching and bludegeoning code to meet functionality requirements while not worrying about software architecture, refactoring, scalability or performance except in passing fads. Yeah, sure it works out of the box like it should, and it has all the checkbox features, and it even looks pretty if that's the look you like, but try and do anything that doesn't ship out of the box and _doesn't_ involve the aforementioned code blugeoning and you end up with a solution that will only work for your specific project because of the Plone-wide assumptions you have to break to get it done. Either that or not give a damn about performance or maintainability and just make it work. Sure, it'll work for a few releases without change if you're lucky, but it'll likely be dog slow and pig ugly if you look behind the scenes. I'm sorry, that kind of coding just doesn't interest me. But, inspite of that, you will see the odd change I've made to try and help, and I try and provide simple tools like zdb, Stepper, MailingLogger, SimpleUserFolder and MailTemplates that people are free to use without any obnoxious GPHell licensing and without having to worry about some semi-formed ip assignment that may or may not stand up in any given court of law around the world. I know you get income from Plone consulting, how about making your workday better *and* pay back for the stuff you get for free? Because I can't. The win's we've had on the one big Plone-related (and there's not _much_ of Plone actually left now, sorry to tell you) project I work on have been by stripping out all the complexity so that code meets the _project_ requirements and doesn't worry about interacting with any of the myriad of Plone half-interfaces and semi finished rubbish that gets shipped as part of every release. You are seriously starting to piss me off, Chris Don't worry, the quality of code that ships in the Plone bundle has already done much to take me way beyond pissed off. I find it a tragedy that a project with such a large following can't manage to get anyone capable of actually standing back and taking a good hard look at the quality of some of your key components and sorting it out rather than tacking on the next whizz-bang feature in a similarly half-arsed manner. - as the only person in the Zope world so far. An achievement in itself, but not one you should be particularly proud of. Honestly, I'm sorry you feel that way but at least I make the distinction about what it is I'm pissed off about. The people in the Plone community are great, and I get on with the majority of them very well as far as I know, but sadly, that alone doesn't make them write good software. I am pissed off with the _software_ not the _people_ and if I thought there was a sane way I could make things better, I would. But again, honestly, I think the software that currently makes up Plone above the CMF, and even that could do with a good kick, is beyond help and would only really be improved by a ground-up rewrite. And finally, if you're pissed off with me, that's fine, I don't really give a monkeys how you feel towards me personally. Write some good software, then I might ;-) cheers, Chris PS: Sorry for the rant, I was hoping to avoid this heading to a list but the one liner I posted earlier was as good as I could make it, I even put the smiley in ;-) For Alex to reply like this has now got the response it deserved. Really, I was excited to try Plone 2.1 with all the hype about the quality being so much better and improved performance, but having just had to give up on another project involving Plone 2.1 and LinguaPlone because it was way too slow, particularly on Windows, and trying to fix any of the problems I found felt like playing some sick and twisted version of whack-a-mole, not to mention the fact that Plone still ships with failing unit tests that cause other product's unit tests to fail means that while I have loads of respect for the project in managing to grow such a large community, and particularly for the people who have the patience to take part, I have zero respect for the software that underpins it... -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Catching logging during unittesting?
Answering my own question and cc'ing Vinay in since I was also talking to him about this... Chris Withers wrote: I'm unit testing something which does some logging. It's supposed to log, so ideally I'd like to test for that, but I'd also like to not have the log spew showing during tests runs, which seems to have started happening in Zope 2.8 :-S I added the following methods to our TestCase base class and then added the class below it: def _stopLogging(self): import logging root_logger = logging.getLogger() self.old_handlers = root_logger.handlers root_logger.handlers = [DummyLogger()] def _startLogging(self): old_handlers = getattr(self,'old_handlers',None) if old_handlers is not None: import logging logging.getLogger().handlers = old_handlers class DummyLogger: def handle(self, record): pass This can now be used in a unit test as follows: self._stopLogging() try: # stuff that ends up logging stuff self.assertRaises(AttributeError,self._runStep,'checkExpires') finally: checkExpires.DateTime = DateTime self._startLogging() Hope this helps someone else :-) cheers, Chris PS: Vinay: lemme know if there's a better way to do this... -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] [dev] RFC: logging/reporting framework for GenericSetup
Jens Vagelpohl wrote: There could be a multiplexer that logs to the standard Zope event log *and* keeps the messages in a memory buffer to be displayed in the browser. This could be done in a separate class or a logging API could be added to ISetupContext. Should be easy to do, really. Well, this is all supported by the logging module ;-) You can define a new log handler just for the duration of the process and then remove it. Have a look at MailingLogger's SummarisingLogger for ideas. Give it a go and let me know where the code is if you want me to take a look, I've got to know and love python's logging module quite well ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Dead branches
Florent Guillaume wrote: Could folks having old CMF branches clean them up ? Why, what's the problem with them? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF-checkins] SVN: CMF/branches/tseaver-pkg_resources/ Avoid using __file__ where possible.
Tres Seaver wrote: Log message for revision 40036: Avoid using __file__ where possible. Why? I use this all over the place so need to know why it's bad ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Biography type
BIll Anderson wrote: Ok, so it's clearly been quite some time since I've done any CMF stuff. Obviously these are not part of Metadata OOTB. What would be the simplest way to add the ability to set/change these? I'd prefer to be able to have them set during the creation process and must be able to change them later. There are no docs I have found for this. I know how to add a property during creation, as well as use it in ZPT. BUT nothing on how to update it from a form. If it was me, I'd just use: .manage_addProperty(name,value,type) ..during creation, and: managed_changeProperties(name1=newvalue,name2=newvalue) ..for editting. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Debugging security settings in .metadata files
Floyd May wrote: I have a set of files - page templates, python scripts, and zsql methods - that are set up as filesystem objects. I'm having trouble getting the security set the way I want it to be with the .metadata files. Here is the content of my .metadata files: --8- [security] View = 0:Manager Access contents information = 0:Manager Access Contents Information = 0:Manager -8-- Did you solve this in the end? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: getActionById replacement
yuppie wrote:
getActionObject(action_path) is the method you are looking for.
getActionById is defined as public, getActionObject as private, so you
can't use it in any skin scripts or templates :-(
Can't see why you would need that method in the skins.
Okay, so how would you get the url for an action from inside a skin
script or template?
Unless someone bribes me I'll not help cleaning up the mess in Plone.
Yes, I wish I didn't have to either, but work with me on this, okay?
I'm not asking you to clean up the Plone mess, I'm asking you to explain
what pattern should be used in CMF 1.5 for something which was common in
CMF 1.4 (I have examples of this from totally non-Plone CMF projects,
and they face the same problems: What to replace getActionById with,
especially when it's used in skin script?)
BTW: IIRC Kapil has a Plone version that works with CMF trunk. That
would mean that he resolved all the deprecation warnings.
Just to emphasise further, I'm looking to document by way of mailing
list archives, what the correct way to replace getActionById calls is,
regardless of whether you're using Plone, CPS, or just plain CMF...
Also, can you explain what type_info.getActionInfo('object/view')['url']
is supposed to return?
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: getActionById replacement
yuppie wrote: This is in a completely set up Plone site? Could you please try to debug those values while we are still in customizePortalTypes? Okay, in there, it's just the normal Plone types, which we don't use. And yes, their _aliases dict appears to have 'view' keys which map to the right thing. So, I guess maybe this is an Archeturds thing? Do they somehow screw up their TI's such that they don't have a sensible _aliases attribute? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-dev] Re: [Zope-CMF] Better DeprecationWarnings (was Re: SVN: CMF/trunk/CMFDefault/Portal.py - reverted Portal.py change of r39125 to fix BBB temporarily)
Tim Peters wrote: Note: sometimes _internals_ use deprecated gimmicks in order to support deprecated gimmicks too, and then stacklevel=3 is too small. It's happened so rarely in ZODB that I haven't tried to do something about that yet. Interestingly, I've found that even this is sometimes not enough, since you don't know whether you want the caller, the caller's caller or further up the chain than that. Is there any way to get the warnings stuff to actually emit a traceback so it can be followed? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Help with Frostbite
robert rottermann wrote: do you have SpeedPack installed? You could always remove that garbage ;-) Frostbite is likely going to be a bigger win, and better written too... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Five views / redirects
yuppie wrote:
def __call__(self):
if self.isTuesday():
return ZopeTwoPageTemplateFile('tuesday.pt').__of__(self)()
return self.index()
Surely the following is going to be better?
tuesday_pt = ZopeTwoPageTemplateFile('tuesday.pt')
def __call__(self):
if self.isTuesday():
return self.tuesday_pt.__of__(self)()
return self.index()
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Trying to customize CMF login to use email rather than userid
Deb Lewis wrote: Configuration: Zope 2.7.7, CMF 1.4.8; also GRUF (GroupUserFolder) 3.3 Why are you using such old and crufty software? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [Zope-dev] RestrictedPython, TALES Expressions and CMF
Sidnei da Silva wrote: CMF seems to create expression contexts in two places off the top of my head: In 'CMFCore/Expression.py' and 'CMFCore/CachingPolicyManager.py'. None of those define 'here' or 'context' but instead just 'object'. I believe one of those two now has context defined in svn HEAD of CMF, but maybe I just patched it locally :-S The question then is, which code is wrong? PageTemplates for relying on 'here' being defined, or CMF for not defining 'here'? I volunteer to provide a fix with tests as soon as someone clarifies which one needs to be fixed. I think we should get to a point where context is defined everywhere and that's what gets used. FSPageTemplate might be a culprit here ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Testing skin scripts and templates using ZopeTestCase.Functional
Paul Winkler wrote:
Aha! I just confirmed that it works as you say in zopectl debug.
(You do have to first make sure that the portal has a REQUEST attribute.)
Yeah, I believe the canonical way is:
from Testing.makerequest import makerequest
portal = makerequest(self.portal)
portal.changeSkin('Nouvelle')
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CMFTestCase: Best way to create the CMF site?
OK, so I misunderstood the actual problem Paul was reporting... Can someone explain it for a stupid person like me? ;-) Chris Stefan H. Holek wrote: Oh, setupCMFSite is sufficiently clever, it's the CMF tests that aren't ;-) Stefan On 5. Okt 2005, at 10:45, Chris Withers wrote: Stefan H. Holek wrote: I see two options: a) Use a different portal name portal_name = 'mysite' CMFTestCase.setupCMFSite(portal_name) Can setupCMFSite not do something more clever if it finds the object already there? -- Anything that happens, happens. --Douglas Adams -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CMFTestCase: Best way to create the CMF site?
Stefan H. Holek wrote: I see two options: a) Use a different portal name portal_name = 'mysite' CMFTestCase.setupCMFSite(portal_name) Can setupCMFSite not do something more clever if it finds the object already there? b) Use getPortal() to create a new portal per test def getPortal(self): manage_addCMFSite(self.app, portal_name) return getattr(self.app, portal_name) hahaha, and watch your tests take hours to run ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Zope Debugger 0.8.0 Released!
Zope Debugger is an enhanced version of pdb for use with Zope. It can be used simply by inserting the following lines in any python code you'd like to debug, including Script (Python)'s and FSPythonScripts: from Products.zdb import set_trace set_trace() It requires no changes to Zope, CMF or Plone or any funky interaction with any specific kind of editing software. All you really need to do is insert the snippet above and make sure your Zope instance is running in foreground mode. For more information, please see: http://www.simplistix.co.uk/software/zope/zdb cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CachingPolicyManager improvements
Tres Seaver wrote: Note that the goal with unit tests is to use the *smallest possible fixture*; using PortalTestCase when you could equally well use RequestTest reduces the usefulness of the test: - it runs slower (the nibbled to death by ducks effect, particularly when re-running the tests frequently, as we all should). - it may mask undesirable dependencies (CMFCore is not supposed to depend on CMFDefault, for instance, even in testing). - it *may* make the tests themselves obscure, because the actual behavior being tested is tied up in lots of extraneous bookkeeping. Hear, hear! (to all of the above) I spent a lot of time long ago making sure CMF had UNIT as opposed to functional tests. PortalPloneTestCase doesn't even try, thanks to the massive dependencies that Plone introduces, so you end up trying to run functional tests all the time which is just too slow. Ask Jens about the project we both work on that now has about 700 tests base on PloneTestCase and how pitifully slow it is, and how we spend a lot of time tracking down problems caused by the huge overhead to having to get Plone fixtures set up just right so that nothing explodes to often... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Small CMFCatalogAware refactoring
Julien Anguenot wrote: The refactoring was obsious and harmless right ? Just removing hardcoded references to portal_catalog and portal_workflow within the internals of CMFCatalogAware. Well, that's not refactoring is it? You've added new functionality with the intent of allowing a new feature, which may, at the very best, raise problems when multiple catalogs are in use, which, as I understand it, is something the CMF is largely predecated against. For example, I've been hoping for a while to do something cleverer in reindexObjectSecurity, but what I had in mind won't work if there's more than one catalog where reindexObjectSecurity needs to work... So I'm with Jens on this one, you could have at least done it on a branch ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Nested skins
Laurence, Could you stick this in the collector so it doesn't get forgotten please? cheers, Chris Dieter Maurer wrote: Laurence Rowe wrote at 2005-8-22 17:04 +0100: ... I often define several skins, and after a while they get a little complicated (I'm using Plone ;-) So in order to make my life easier I thought it would be nice to be able to define a skin 'Foo' like: foo_skin My Standard Skin This would then get expanded to include all the layers of 'My Standard Skin' after the layer foo_skin. Attached is my patch implementing this, would it be useful for anyone else? Yes, even very useful. -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)
Tres Seaver wrote: Exactly. The point is that the adverse effect *already happened*, in some prior request, probably due to one of Chris' beloved hasattrs ;). The current request should *not* be prevented from continuing. Why not? Chris, take this as a fiat: this one will *never* turn into an exception. It's already an exception, you and Florent seem intent on burying that fact. Can you give me some specific examples in the past of where this has been of benefit? Every single time I've encountered this, the fact that the exception is caught has been a total hinderance :-( That said, I'm also aware that there are currently 4 of us talking about this, 2 on each side. What does the rest of the community think? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [CMF-checkins] CVS: Products/CMFCore - DirectoryView.py:1.47.2.7
Dieter Maurer wrote: You asked for this a long time ago and I responded (a long time ago!): You turn the warning (all of them, if you like) into exceptions and you get a nice traceback. You find details in the description of the Python (command) options or the module warnings. OK. Thanks. Having had a hunt around, I see there's also a Zope.conf section for this... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [CMF-checkins] CVS: Products/CMFCore - DirectoryView.py:1.47.2.7
Hi Florent, Florent Guillaume wrote: I deliberately didn't use a LOG call, because this line will get executed for every request if there is an old directory view present, and it'll fill your logs pretty quickly, which is not acceptable. Well, what's acceptable or not is a matter of opinion ;-) Disk space is cheap and I don't mind logs filling up with this, as it's a good sign it needs fixing quickly. Using warn was the quickest alternative that worked, if you have something better... So are you saying that warn will only emit the warning once no matter how many times it's called? Interesting, that might explain the existence of this otherwise apparently meaningless module in the python standard lib ;-) If that IS the case, how do I get warning messages to be copied to the event log? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Problem when setting Portal Image as index_html
Dinh Trung Viet wrote: It seems that Portal Image cannot display the image when it was set as default page i.e. id = index_html. Anyone has the same problem before? I'm using Plone 2.0.5. Go ask on the plone list then ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Where can I found information about CMFCore class DirectoryRegistry ?
KLEIN Stéphane wrote: I search information about CMFCore class DirectoryRegistry. What is it ? How use it ? ... Where can I found information about it ? Here's a better question: Why do you want to know how to use it? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Where can I found information about CMFCore class DirectoryRegistry ?
Well, the source code is it. You don't need to worry about any of these though, if you just want to change and add some fields.. cheers, Chris KLEIN Stéphane wrote: Chris Withers a écrit : KLEIN Stéphane wrote: I search information about CMFCore class DirectoryRegistry. What is it ? How use it ? ... Where can I found information about it ? Here's a better question: Why do you want to know how to use it? I want to customize CMFEvent product to change and add some field. I look __init__.py file and I see some mysterious things : * registerDirectory * utils.ToolInit * utils.ContentInit * utils.initializeBasesPhase1 Where can found information about it, apart source code ? cheers, -- Stéphane -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
