RE: [Zope-CMF] Access rule for setting skin
[EMAIL PROTECTED] wrote at 2005-4-4 11:37 -0400: ... As I think I'd mentionned, I get the Zope default home home page (Welcome to Zope, etc ...), but with a big warning at the top telling me that I don't have an administrative user setup and so on ... Which is obviously not true :) Fine. But, I am unable to keep track of everything written in a thread... Further reading has suggested that the problem might be because the hook occurs before any authentication occurs, so the changeSkin() method will not work properly, or something like that? Saw some archived list discussions on this topic ... Post-authentication hook? This should only be a problem when your changeSkin decision were based on specific user identities or authorization. Such information is not available in an AccessRule as authentication is performed after traversal (while AccessRules are executed during traversal). In fact I believe you have a patch for it on your site? Yes -- for a post-authentication hook. But, as explained, it will not help for your current problem. Putting the access rule higher I'm guessing wouldn't work. It's already in the root of the CMF site. Putting it in the root of the entire zope instance would move it outside the CMF, and changeSkin() would no longer be easily available, or work properly? (Admitedly, haven't tried it yet). Of course, you would need to traverse to the object which defines changeSkin... If that's not it, I also discovered a co-worker developped a custom class that does what I need by using registerBeforeTraverse. I think I may do that anyways as it allows my code to be on the FS and version controlled and so on. Fine! -- Dieter ___ 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] [Performance] listFilteredActionsFor unnecessarily expensive
In our regular profiles, listFilteredActionsFor belongs to the top consumers of CPU time. Recently, I found the main culprit (in CMF 1.4): It is the completely unnecessary: if not action in catlist: In our case, listFilteredActionsFor spends about 70 percent of its complete time in the checking of action in catlist. How in hell should the same action be defined more than once such that we need to prevent such a case by an explicit check -- especially by such an expensive one? A comment before the line indicates that the author intended to check by identity. But, of course, action in catlist does *NOT* check by identity but by equality. I propose to remove the check altogether... -- Dieter ___ 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] failing tests and other unit test issues
yuppie wrote at 2005-4-4 20:59 +0200: ... 2.) I prefer to see the correct import in each file and to use utils just for the fallback. But, then you get a nasty try: ... except: in hundred of files rather than just a single one. -- Dieter ___ 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: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)
Florent Guillaume wrote at 2005-4-22 17:17 +0200: Chris Withers [EMAIL PROTECTED] wrote: ... Yes we do! I really really really want to know if: - I have a catalog entry that points to an object that no longer exists. This can ONLY happen due to a bug somewhere and needs to be fixed - I have index corruption or other weirdness - any of the above are happening, and be able to descriminate between them. I honestly can thing of no sane justification for putting that None there. It's tantamount to a bare try except, and without even any logging. I rarely agree with Chris -- but this time I do :-) Yes, logging should be there. I'll add a LOG at level WARNING somewhere, I'm not sure where (after all it's unrestrictedTraverse that does the catching). When something in the catalog tells you, there were an object and the object is not locatable, then this is an ERROR and not a WARNING -- because, you met a data inconsistency. Data inconsistencies are serious enough to be classified as ERROR. -- Dieter ___ 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] How to use typesTool.manage_addTypeInformation ?
KLEIN Stéphane wrote at 2005-5-5 19:40 +0200: ... typesTool.manage_addTypeInformation( add_meta_type = factory_type_information['meta_type'], id = factory_type_information['id'] ) ... File /home/harobed/newzope/Products/ZHelloWorld/Extensions/Install.py, line 22, in install ) File /home/harobed/newzope/Products/CMFCore/TypesTool.py, line 598, in manage_addTypeInformation raise ValueError, ( ValueError: Meta type ZHelloWorld is not a type class. The add_meta_type must refer to a class described by Products.CMFCore.TypesTool.typeClasses. By default, typeClasses describes just FactoryTypeInformation and ScriptableTypeInformation. Obviously, your add_meta_type does not fulfill this requirement. -- Dieter ___ 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] Multiple User Folders
Chris Crownhart wrote at 2005-5-16 10:28 -0600: ... I am building a CMF site that will have many organizations (could be up to 200 or 300). Each organization will have it's own set of users, and probably it's own set of roles, although most of the roles will be the same across all organizations. I have a couple questions, and really am just kicking some thoughts around, and would be curious as to anyone's ideas. 1. Should I consider having separate User Folders (I'm using GRUF) for each organization? This makes sense for a lot of reasons. Users of one organization will probably never be in another, so why clutter up one huge User Folder? 2. Should I consider just having separate CMF sites for each organization? This would offer the ultimate in flexibility, but would probably be a maintenance nightmare. I don't have any idea how many CMF sites I could have on one server, but I'll bet the number is pretty high. I would probably go for this solution. These sites can share a large amount of templates and logic (if they wish). -- Dieter ___ 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
Chris Withers wrote at 2005-5-26 08:12 +0100: ... My personal hate of it comes from seeing a thoroughly useless warning coming from the old SearchIndex stuff for years and never being able to figure out exactly what was causing the problem. 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. -- Dieter ___ 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: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)
Florent Guillaume wrote at 2005-5-27 13:30 +0200: ... Let's not go into too much semantics here. Note that WARNING is an alias of PROBLEM. zLOG defines these levels as: PROBLEM=100 -- This isn't causing any immediate problems, but deserves attention. ERROR=200-- This is going to have adverse effects. And indeed the missing object isn't causing immediate problems. But just because you catched the resulting exception... An inconsistency between the catalog and its object world is an adverse effect. -- Dieter ___ 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: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)
Raphael Ritz wrote at 2005-6-3 09:40 +0200: Chris Withers wrote: [..] 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? Since you ask so explicitly ;-) I agree with Florent: Your site's _USERES_ should never get an error thrown at. There are other ways to inform the site's admin. But admins are lazy people (I am one, part time; therefore, I know...) *unless* their users report problems. I know that lots of admins saw lots of inconsistency reports in Zope's logfile -- and did nothing! Only newbies asked from time to time what these log entries mean -- and got the advice to ignore them... I speak about the could not remove XXX from index III that plagued Zope's KeywordIndex for years. -- Dieter ___ 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
Maya Angelova wrote at 2005-6-17 10:26 +0200: I have a the following problem by restarting a plone site under zope. Could anybody give me a hint. would be very grateful sh plone2 restart plone2: line 156: plone2 : command not found plone2: line 158: plone2 : command not found These are problems reported from the shell script plone2. In its line 156 and 158, it references unknown commands. Check which commands these are and why they are unknown. In case, you have bash installed, try to use bash in place of sh. -- Dieter ___ 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: Conflict between PortalFolder and CMFBTreeFolder
Julien Anguenot wrote at 2005-6-20 11:19 +0200: Christian Heimes wrote: ... I'm proposing to change PortalFolder in the following way: * Revert PortalFolder to be subclassed from Folder * Create an OrederedPortalFolder as subclass from OrderedFolder * Subclass all classes in CMF from OrderedPortalFolder instead of PortalFolder All third party software that was working with CMF 1.4 and older would work as expected and all CMF core software would still use the ordered folder. The downside is that software written for CMF 1.5 has to be altered. But it is much easier to alter a few lines in some products than trying to get rid of the ordered stuff in PortalFolder. - -1. You can change the code of your product to cope with it. (i.e : we did this on CPS a long time ago) I, on the contrary, am in favour of such a change. CMFBTreeFolder demonstrates that there is a useful use case for a PortalFolder *without* order support. *AT LEAST*, there should be a PortalFolder base class without order support (which might have a different name). -- Dieter ___ 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] CMFSetup: non-ascii text
Florent Guillaume wrote at 2005-7-1 17:19 +0200: In many places, CMFSetup exports and imports things like titles and descriptions. For instance, for the workflow states and transitions. These fields can often, outside the USA, contain non-ascii strings. How do we export and reimport them ? 1. We can export by converting them to unicode, and the ZPT will render that as UTF-8. Which charset do we assume ? Anything better than locale.getlocale()[1] or 'latin1' ? 2. When importing, do we set the values (attributes) as unicode, or do we try to re-convert to the above charset... I think, we should keep all text as Unicode -- even in english speaking environments If this is not an option, the external format should use Unicode and some configuration parameter (Plones uses site_encoding) converts from/to the external Unicode. -- Dieter ___ 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] undo_form - no content
David Chandek-Stark wrote at 2005-7-27 09:51 -0400: I got no reply from plone-user on this issue -- I believe it's really a CMF issue anyway. Add CMF 1.4.7 to the version info below. Probably, because your question is not too clear... ... In my site the undo form is always blank. In the ZMI, however, undoable transactions are listed. Thus, you speak of what undo form? Apparently, the undo tab of the ZMI lists what you expect, but something else does not. What is this something else? -- Dieter ___ 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: undo_form - no content
David Chandek-Stark wrote at 2005-7-27 16:10 -0400: Sorry, this is a Plone site. There is a Plone skin template undo_form which calls container.portal_undo.listUndoableTransactionsFor(here) to get the undoable transactions. Not sure, whether Plone uses its own UndoTool. The CMFCore UndoTool should show a user with the ManagePortal permission the same undoable transactions as the Undo tab of the portal's ZMI page. Other users will only see their own transactions. -- Dieter ___ 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: undo_form - no content
Sam Brauer wrote at 2005-7-29 08:19 -0700: I've recently encountered a similar problem, and I'm not using Plone. I'm in the process of migrating some CMF sites to Zope 2.7.7 and CMF 1.5.2, from Zope 2.7.2 and CMF-1.4.8. With the newer software, I find that users who are defined in the site's acl_users (even with the Manager role) never see any transactions listed on the undo_form, while users defined in the main acl_users at the root of the zope instance do see transactions listed. I remember (faintly) to have read in this list that there have been recent changes with respect to undo that break the CMF. Please search the archive... -- Dieter ___ 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: Plone participation in the CMF list
Geoff Davis wrote at 2005-8-1 12:53 -0400: ... * Are there any particular things in Plone that you think should be pushed down into CMF? PloneBatch seems quite useful. I do not use Plone (due to its GPL) but I found the FactoryTool useful. Because it is GPL, I studied its functionality and then made my own implementation (independant of the Plone one). -- Dieter ___ 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
yuppie wrote at 2005-9-5 14:06 +0200: ... PortalTestCase is in the wrong layer. It makes assumptions about the way CMF works. Changes to the CMF might break PortalTestCase and create a dependency on a new Zope release. (We saw that problem already with the _refreshSkinData changes in CMF 1.5) It is not better to fix such problems at a single place (PortalTestCase) rather than in lots of individual tests (that happen to make similar assumptions)? -- Dieter ___ 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] Topic changes: problems with revision 38002
yuppie wrote at 2005-9-21 18:10 +0200: ... File Products/CMFDefault/Portal.py, line 26, in ? from Products.CMFTopic import Topic ImportError: cannot import name Topic In a similar situation (with Archetypes) something like import Products.CMFTopic.Topic; Topic = Products.CMFTopic.Topic worked around the problem. -- Dieter ___ 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: IE Cache Bug and CachingPolicyManager
Geoff Davis wrote at 2005-9-28 13:31 -0400: On Wed, 28 Sep 2005 12:47:06 -0400, Tres Seaver wrote: Thanks for the analysis, and the fix (sorry for the earlier, premature reply). No problem. P-J Grizel suggested offline that the problem might be due to IE not parsing the time zone string at the end of the Last-Modified date stamp correctly. HTTP 1.1 specifies: All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated Universal Time). This is indicated in the first two formats by the inclusion of GMT as the three-letter abbreviation for time zone, and MUST be assumed when reading the asctime format. Thus, there *MUST* not be any time zone different from GMT. -- Dieter ___ 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] DCWorkflow + Acqusition
Victor Safronovich wrote at 2005-10-11 14:04 +0600: I have a question about DCWorkflow, WorkflowTool and Acqusition. My object, during change state, move to another folder and should change acqusition wrapper. workflow_tool = getToolByName( my_object, 'portal_workflow') workflow_tool.doActionFor( my_object, 'some_action' ) # during doActionFor raised ObjectMoved but i don`t know about that in here # because WorkflowTool._invokeWithNotification shallow it. But it returns what objectMoved.getResult() returns. You can use this to communicate with the doActionFor caller. The much more reliable way however is to perform the necessary unindexing and recataloging inside the action itself (and not let this as task of the caller). -- Dieter ___ 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: RestrictedPython, TALES Expressions and CMF
Tres Seaver wrote at 2005-10-11 08:58 -0400: ... 'call_with_ns' should be invoked only for objects with either a '__render_with_namespace__' attribute (PythonScripts fit here) or those with 'isDocTemp' true. Its only real purpose is to set up the namespace before calling a DTMLMethod; I don't even understand why PythonScripts have such a method. Probably, because they can bind the DTML namespace... -- Dieter ___ 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: RestrictedPython, TALES Expressions and CMF
Tres Seaver wrote at 2005-10-16 14:22 -0400: ... Probably, because they can bind the DTML namespace... I knew that they *could* bind it; it just don't understand why anyone would *want* that feature, given the availability of the other, non-ambiguous bindings. I know that I used it intensively in the past (for a former employer). Now, I almost dropped DTML and with it the DTML namespace bindung of Python Scripts, although it works as well with the ZPT namespace... I would argue that it is a misfeature, especially given the bug which it surfaces in 'render' / 'call_with_ns'. I have seen this several times: When a bug comes to the surface, a feature is reclassified as a misfeature... I do not need this feature (unlike other reclassified things) but maybe, fixing the bug is also a solution? =nIvs -END PGP SIGNATURE- -- Dieter ___ 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.5 manage_afterAdd co
Florent Guillaume wrote at 2005-11-9 16:17 +0100: ... To make sure that CMF 1.5.5 will play well with Five 1.2, I have to make sure that no method manage_afterAdd redoes a recursion that one of its base classes was doing, as we have to be prepared to have the base class monkey-patched to use events, and have recursion done with events. ... Does someone have a problem with me doing that in the CMF 1.5 branch? Test with with Archetypes and Plone... Archetypes does a nice dance with manage_afterAdd. If fact, it gets it wrong (such that objects are indexed much more than once). -- Dieter ___ 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: Proposal for hooking rendering
Paul Winkler wrote at 2005-11-30 10:33 -0500: ... When you customize a FSPageTemplate, you get a plain ZopePageTemplate. So you'll need to find a way to post-process the output of those without requiring a change to core Zope, or this becomes a Zope proposal. Unfortunately I haven't a clue how you could avoid that. Instead, you change the makeZODBClone (or similar method) of FSPageTemplate and create a (new) CMFPageTemplate. (rather than a plain ZopePageTemplate). This would be a good thing (not only in the light of Paul's proposal) as a plain ZopePageTemplate behaves too differently from a FSPageTemplate (i.e. it is not Caching Policy Manager aware). -- Dieter ___ 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: Proposal for hooking rendering
Sidnei da Silva wrote at 2005-11-30 18:26 -0200: On Wed, Nov 30, 2005 at 08:24:56PM +0100, Dieter Maurer wrote: | Paul Winkler wrote at 2005-11-30 10:33 -0500: | ... | Instead, you change the makeZODBClone (or similar method) | of FSPageTemplate and create a (new) CMFPageTemplate. | (rather than a plain ZopePageTemplate). | | This would be a good thing (not only in the light of Paul's | proposal) as a plain ZopePageTemplate behaves too differently | from a FSPageTemplate (i.e. it is not Caching Policy Manager aware). But then again, neither is FSImage/FSFile and OFS.Image/OFS.File. Indeed, all of them should be fixed. -- Dieter ___ 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: VIRTUAL_URL and ACTUAL_URL (was Re: Collector Issues)
Alexander Limi wrote at 2005-12-3 14:27 -0800: ... Except, the implementation did not end up including the query string - which was the whole idea in the first place, to have ACTUAL_URL be what is in the address bar right now, so things like anchors work (did you know there is no proper way of getting anchors to work in virtual hosting setups without doing three conditional tests in your template?). I have difficulties to understand the paragraph: What have anchors to do with the query string? As I understand it, anchors (fragments in the URL) are a client only concept: fragments are not transfered to the server. -- Dieter ___ 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: VIRTUAL_URL and ACTUAL_URL (was Re: Collector Issues)
Alexander Limi wrote at 2005-12-4 20:04 -0800: On Sun, 04 Dec 2005 10:23:25 -0800, Dieter Maurer [EMAIL PROTECTED] wrote: What have anchors to do with the query string? As I understand it, anchors (fragments in the URL) are a client only concept: fragments are not transfered to the server. Correct, but it's impossible to construct valid anchors that do not reload the page if you do not have a working ACTUAL_URL because of Zope setting the base value to something else than the current page. Thus, a link like a href=#someanchor / will *reload the page*, then go to the anchor - which is clearly not desirable behaviour. Okay, I understand. But, that ACTUAL_URL does not contain the query string cannot be the problem because you can easily add it. Determining the real ACTUAL_URL is unfortunately not that easy because * HTTP allows proxies to change the URL (that's why RFC2617 transfers the uri in 'Authentication' and does not trust the request uri) * Apache's mod_proxy is often used to modify the URL to include commands for the VHM * Right at the beginning of request processing, before VHM has a change to do its job, the URL is modified by Zope (executing :action/method requests) * The URL is modified again during traversal -- at some point of which the VHM does its job It will not be that easy to get it right with all of these influences. Probably the most promising route would be let VHM determine ACTUAL_URL from PATH_INFO by removing/executing its commands on it. It will probably work only in standard situations (VHM in Zope route, e.g.). -- Dieter ___ 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] FS Skins and Last-Modified
Doyon, Jean-Francois wrote at 2006-1-25 15:51 -0500: ... FSDTMLMethods ... But, for some reason, now it seems bobobase_modification_time comes out wrong :( It's stuck at some date in October, even though the files are far more recent. Note that the methods (like bobobase_modification_time) inside an FSDTMLMethod do not act on the FSDTMLMethod but on its (so called) client. The model is like this: The FSDTMLMethod is called for an object, its client. Most methods used inside the FSDTMLMethod from the DTML namespace come in fact from client (or are acquired by it). Therefore, bobobase_modification_time give you the modification time of the ZODB (!) object that happens to be the FSDMTMMethods client. When called from ZPublisher (as is apparently your case), the client is the object located during URL traversal before the FSDTMLMethod (REQUEST.PARENTS[0], to be precise). -- Dieter ___ 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] [DCWorkflow]Problem with initial state
Encolpe Degoute wrote at 2006-3-7 20:33 +0100: I found something funny yesterday that makes me spend some hours: If you delete the state marked as initial state the variable initial_sate always contains its id. Any workflow needs an initial state. Thus, maybe, you should mark a new state as initial once you deleted the old one? In many cases, deleting state is not a good idea (at least not when there are objects in the deleted state). -- Dieter ___ 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
George Lee wrote at 2006-3-8 10:17 -0500: If I want a class to appear in the ZODB, is that just a matter of subclassing SimpleItem? Usually, classes do not appear in the ZODB -- just their instances. SimpleItem is the base class of all (what I call) Zope site building objects -- the term Zope site building object may correspond to your may appear in the ZODB. Perhaps, you will find reading http://www.dieter.handshake.de/pyprojects/zope/book/chap3.html useful. What additional attributes do I need to set -- for instance, do I need to define 'meta_type' for the class? meta_type is usually used in the so called add list. It should be a unique description of your object class such that you are able to select the object from the add list when you need it. You use ObjectManager._setObject(id, obj) to put obj into the ObjectManager. Note, that you must also give obj the identical id. Otherwise, URL generation will break. Can a class be persistent but not have its instances appear in the ZODB Yes. You can instanciate a class deriving from Persistent without the instance to actually get persisted. It only gets persisted when you assign it to an attribute of a persisted object. You may want to read the ZODB guide. -- Dieter ___ 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] Implicit and Acquirer
George Lee wrote at 2006-3-11 00:41 -0500: ... What is the difference between Implicit and Acquirer? Between Explicit and Acquirer? An acquirer is an object with two components aq_self and aq_parent. If asked for an attribute, any acquirer passes the request on to aq_self and returns the result if aq_self can deliver the attribute. The difference between an ImplicitAcquirer and an ExplicitAcquirer comes only into play when aq_self cannot deliver the asked for attribute. In this case, an ImplicitAcquirer automatically passed the request on aq_parent while an ExplicitAcquirer fails (with an AttributeError). Including, what methods do Implicit and Explicit *add* or *override*? Both have the same methods (and attribute). For instance, does Explicit add an aq_acquire method? No. But aq_acquire is more important for an ExplicitAcquirer than for an ImplicitAcquirer: aq_acquire supports precise control over the lookup behaviour of all kinds of acquirers. With an ExplicitAcquirer, you (usually) must use aq_acquire to look the attribute up in aq_parent; an ImplicitAcquirer would do this automatically (if necessary). What else? Nothing. I tried sifting through the C code and the epydoc files but still couldn't make sense of it all -- it seems that Implicit and Acquirer are really the same, for instance. Answers or references would be very appreciated, thanks. Apparently, you have a reason to use the strange Implicit and Acquirer... In fact, there are two kinds of Acquirers: ImplicitAcquirer and ExplicitAcquirer. There is nothing like Implicit and Acquirer. -- Dieter ___ 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] Implicit and Acquirer
George Lee wrote at 2006-3-12 00:05 -0500: ... Other than understanding how Python wraps C classes -- is there anyway of seeing where the classes are defined, understanding the methods + method definitions, in a Python-looking way? The DocFinder (or DocFinderTab) shows you the modules classes are defined in. If they are defined in Python, you can directly switch to the code. This does not work for C implemented classes. -- Dieter ___ 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: [dev] characters allowed in content IDs
yuppie wrote at 2006-3-21 21:12 +0100: There was a clear result: make the id checker policy configurable -- as Zope 3 does. Well. That's right but doesn't help us much. We don't have a volunteer for implementing that new feature. And we don't have a consensus what the default policy should be. If the policy were pluggable, I think that nobody would object to follow your proposal to use the Zope3 default. ... Why should I make it configurable? Because it would be the right way to do it and because it seems to be the prefered solution by the community. I volunteer to fix a serious bug by restoring behavior we had until 6 months ago. An INameChooser based configurable solution would be much more work than just fixing the bug. The same arguments apply in CMF land as in Zope land. You deleted the sentence in which I said what's different IMHO: In CMF we plan to use views by default and it's quite common that normal site members are allowed to add content items. So it's more urgent to fix the bug in CMF than in Zope. I would prefer a mechanism as the current CMF uses it: Prevent the creation of a content object only when it really conflicts with something. Or at least, prevent only ids starting with @@ or ++ (as these are the prefixes really used by Zope 3, right?). As mentioned in zope-dev, I am primarily concerned with WebDAV integration. And our WebDAV using projects are in fact CMF based. On the other hand, if I am the only objector, do what you propose. I am able to change it in our Zope version to fit our needs. -- Dieter ___ 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 in setting local roles for newly created object
Bartek Gorny wrote at 2006-3-29 11:50 +0200:
...
I have a script which creates a new instance of a certain portal_type
by a method constructContent, and then calls manage_setLocalRoles.
And I get an exception:
Module AccessControl.Role, line 362, in manage_setLocalRoles
AttributeError: __hash__
and the lines in question are:
361dict=self.__ac_local_roles__ or {}
362dict[userid]=roles
This means, the userid does not have a __hash__ method
and especially is not as string. But, it should be a string!
--
Dieter
___
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] [Optimization] listFilteredActionsFor
Yuppie already has considerable sped up listFilteredActionsFor for CMF 1.5. However, even after his optimizations listFilteredActionsFor can still consume lots of time. I found simple situations where it had spend more then 10 percent of total request time in testCondition. I propose to make the category lists lazy objects that perform condition and permission evaluation only when they are accessed. This means that action categories not used on a specific page would not have the expensive testCondition evaluated. -- Dieter ___ 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] CachingPolicyManager and Image/File content
Bert Vanderbauwhede wrote at 2006-4-5 15:19 +0200: ... I'm currently setting up a CMF site for testing purposes. While configuring the CachingPolicyManager, I discovered that it didn't work for the Image and File content types. However, it worked perfectly for the Document content type. I only got it working for Image and File after I modified the index_html() method in CMFDefault/Image.py and CMFDefault/File.py. Anyone knows what I'm doing wrong? Or is this a known problem? You may look how I made FSFile and FSImage CachingPolicyManager aware. The change is now in CMFCore. -- Dieter ___ 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] 'request' in expression context
yuppie wrote at 2006-4-26 18:25 +0200: In createExprContext 'request' is currently set to getattr(object, 'REQUEST', None). 'object' might be None, making 'request' None as well. Would anybody mind if I change that to getattr(portal, 'REQUEST', None)? AFAICS portal is always available and can acquire REQUEST. If there are no objections I'll fix this in CMF 1.5, 1.6, 2.0 and trunk. A very good idea! -- Dieter ___ 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: Products-less python package support for CMF 1.6
yuppie wrote at 2006-6-4 18:12 +0200: ... AFAIK registerDirectory and registerProfile work only inside of Products. At least in CMF 1.5, registerDirectory works outside Products, too. Due to some bad design, it stops working when Products is somewhere inside the path (even if not a complete segment) and this is not meant as the Products directory. -- Dieter ___ 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] CachingPolicy
LESUEUR Frédéric wrote at 2006-6-22 15:08 +0200: i have a question about the _setCacheHeaders methods inside this file CMFCore/utils.py. Why content is set to aq_parent and not the object itself ? The model (underlying the caching policy manager) is that templates (views) access content objects. In the code above object is (usually) the template, object.aq_parent is the object viewed by the template -- i.e. the content object in the model above. You are right that the model often does not fit: it does not, e.g. for FSFile and FSImage objects (now fixed in the core). But it also does not fit when the template is used in its own right and not as a view, e.g. a FSDTMLMethod generating a style sheet. The model mentioned above it too narrow. It should be extended by an additional variable target (or something similar) which is the object traversed to. This might give the policy handlers enough information to distinguish between the template views content and template is content itself cases. ... The test of a policy is make with parent of object not this object. If i have a FSImage, the test is make with this context parent and no http cache is set. This, meanwhile (CMF 1.5 and up) should have been fixed. -- Dieter ___ 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] CachingPolicy
Frédéric LESUEUR wrote at 2006-6-23 10:03 +0200: Le Jeudi 22 Juin 2006 20:00, vous avez écrit : LESUEUR Frédéric wrote at 2006-6-22 15:08 +0200: This, meanwhile (CMF 1.5 and up) should have been fixed. ok thanks, this is what i'm thinking, it fail with object that are call without view (like stylesheet or FSImage ...). Maybe it's ok with newer version of CMF (=1.5), i can't test at this time. It's a CMF (1.4.7) inside a version 3.2.3 of CPS. If you care, you can backport the change to your older CMF version... Of course, upgrading might be a better option... -- Dieter ___ 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: DirectoryView, GenericSetup/skins, CMF 2.1
yuppie wrote at 2006-7-14 11:30 +0200: ... We have a Zope version where package resources (such as skins) can come together with the package from a zip archive (this is a function similar to the newer egg Python function). We identify such resources via pypackage urls which have the form pypackage:package/path Here package is the full package path (e.g. path.to.some.package). ... Please note that in CMF 2.1 this is just a registry key for looking up DirectoryInformations. It is no longer used for looking up the filesystem resources directly. The identifiers discussed here are useful for direct lookup, but IMHO they are overkill for registry lookup. When I remember right, the original question was how these keys are represented externally -- in a GenericSetup profile. And there, such a representation may well be adequate... -- Dieter ___ 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: returning case insensitive matches for portal_membership.searchMembers()
Norbert Marrale wrote at 2006-8-4 17:53 -0400:
...
Which brings me to my original Q...
Is there a better way than the two-step approach I'm following:
emails = context.portal_membership.searchMembers('email','')
and then iterate over emails to find the matches
if (member==string.lower(emails[n].values()[1])):
You could maintain an additional dictionary mapping the
(normalized) email address to the user id.
If you do not have such a mapping, then your code above is
as efficient as it can be.
--
Dieter
___
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] strange problem fixed by _owner
Miles Waller wrote at 2006-8-11 16:17 +0100: ... I stepped through the code and somehow it thinks the user 'admin' is the owner. I think this is being acquired from somewhere (not sure where). I added the line _owner = None at the class level in CMFCore.DTMLMethod (analagous to that in CMFCore.FSPythonScript) and everything worked correctly but I'm confused. If assigning to _owner changes something, then the issue is with the executable ownership (this is maintained in _owner). An executable object (in this case your DTMLMethod) cannot have more permissions than its (executable) owner. In your case, the executing user has more permissions -- but this does not help. You may be able to change the executable owner of your DMTLMethod with the Take ownership tab of the object. -- Dieter ___ 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] caching policy manager
Jens Vagelpohl wrote at 2006-9-13 09:15 +0200:
...
It is a long-standing bug that the CMFDefault File index_html (and
download, which is obsolete in newer CMF versions) simply defers to
index_html from OFS.File. That one doesn't know anything about Cache
Policy Managers, it only deals with the Zope ZCacheable cache manager
mechanism.
I have defined CMF-aware ZODB object types. The one for File looks
like this:
# DM 2005-11-02: added
CMF 'File' variant (CMF Cache Policy Manager aware)
from OFS.Image import File, manage_addFileForm, cookId
from utils import _setCacheHeaders, _ViewEmulator
class CMFFile(File):
'''CMF cache policy manager aware file.'''
meta_type = 'CPM aware File'
def index_html(self, REQUEST, RESPONSE):
' '
r = File.index_html(self, REQUEST, RESPONSE)
if self.ZCacheable_getManager() is None:
# not none cache manager already taken care of
_setCacheHeaders(self._getCPMCachingWrapper(), extra_context={})
return r
# DM 2006-05-17: more modular CPM caching
def _getCPMCachingWrapper(self):
return _ViewEmulator().__of__(self)
# essentially a copy of OFS.Image.manage_addFile -- we should probably
# use ReuseUtils.
def manage_addFile(self,id,file='',title='',precondition='', content_type='',
REQUEST=None):
Add a new File object.
Creates a new File object 'id' with the contents of 'file'
id=str(id)
title=str(title)
content_type=str(content_type)
precondition=str(precondition)
id, title = cookId(id, title, file)
self=self.this()
# First, we create the file without data:
self._setObject(id, CMFFile(id,title,'',content_type, precondition))
# Now we upload the data. By doing this in two steps, we
# can use a database trick to make the upload more efficient.
if file:
self._getOb(id).manage_upload(file)
if content_type:
self._getOb(id).content_type=content_type
if REQUEST is not None:
REQUEST['RESPONSE'].redirect(self.absolute_url()+'/manage_main')
def initialize(context):
context.registerClass(
CMFFile,
permission='Add Documents, Images, and Files',
constructors=(manage_addFileForm,
manage_addFile),
)
--
Dieter
___
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] CachingPolicyManager
Miles Waller wrote at 2006-10-11 16:34 +0100:
...
output_page_2:
==
h2Here is the subtitle from template 2/h2
2. Add a rule to the cpm as follows:
id: template_test
predicate: view.endswith('_2')
etag: string:template_test
3. Make a request for yoursite/output_page_1
4. Note that the caching rule for output_page_2 is applied
This is because the cpm is called whenever a FSZPT is called - so the
call to the second template causes it to check it's rules again.
My question is, does this count as a bug?
I would say yes...
Please file a bug report to the CMF collector.
--
Dieter
___
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] CachingPolicyManager
Jens Vagelpohl wrote at 2006-10-11 12:03 -0400: ... I'm not sure this can be called a bug. It is true (and perfectly normal) that rendering a filesystem page template will always call the CPM. You're rendering both here. Since output_page_2 is rendered last as it's calles from output_page_1 the rule for output_page_2 fires and will overwrite existing headers/add new headers according to the rule that fires. The problem here is that both happen in the same request, the rendering code does not distinguish betwen the primary and the nested rendering. Thus, this *is* the bug. It should distinguish between primary and nested rendering. Unfortunately, the bug is probably deep -- affecting the complete cache integration. Even more importantly, for a RAM cache it may even be a good thing that the nested rendering can cache in addition to the primary rendering. -- Viele Grüße Dieter Tel: 06894-870 177 ___ 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] _checkEmail issues
Charlie Clark wrote at 2006-10-20 15:50 +0200: ... There is a module for testing domains against a DNS which is much more reliable. Regarding the rest I normally check with the responsible MX server as negatives are usually reliable. DNS queries can take quite a long time -- and we have seen quite a few cases where the DNS query timed out for perfectly valid domains. -- Dieter ___ 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] [Warning] Danger from Zope caching, especially the CMF Caching Policy Manager
Crosspost: 'Reply-To' set to 'zope-cmf'.
We nearly escaped a catastrophy: a page with sensitive personal
information ended in a shared cache and was delivered to arbitrary
people. This happened despite the fact that the template generating
the page contained a response.setHeader('Cache-Control', 'no-cache')
(and related headers for non HTTP/1.1 clients).
The analysis quickly revealed broken design in the
CMF Caching Policy Manager (CPM)
as the cause:
* it has applied its general policy depite the fact that
the template itself has provided more adequate decisions with
respect to caching
* the caching policy manager action affects the complete response.
Therefore, only the top level object, the object that controls
the response content, should influence the CPM decisions.
In the concrete case, the primary template did not trigger
the CPM but the call of a secondary template responsible only for a tiny
part of the response.
The same problem also affects Zope's HTMLCacheManager.
The description indicates in what direction the CPM should get fixed:
* If the response already provides cache control, the CPM should
not override it, as it is likely that the specific information
available to the response generating process is more trustworthy
then the general CPM policies.
This is arguable, especially as it changes the current behaviour.
Maybe, it should be controlled by an additional configuration option.
* The CPM (and Zope's HTTP Cache Manager) must set cache headers
only based on the object that generated the (complete) response
entity and not based on other objects called during the request
(and probably only responsible for part of the entity).
--
Dieter
___
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] [Warning] Danger from Zope caching, especially the CMF Caching Policy Manager
Jens Vagelpohl wrote at 2006-12-17 19:57 +0100: ... I don't know if it is possible to have any sane policy about what to do if the response already has caching headers. First of all, when should this exception policy trigger? Which headers should tell the CPM that someone else already decided on caching? Secondly, what is the behavior supposed to be? Do nothing? DWIM? This obviously needs exact specifications and use cases. The HTTP/1.1 specification tells us what cache-control headers are for and we can deduce from it how to merge concurrent cache controls when the aims of HTTP/1.1 are respected (ensure semantic transparency). I sketched this in the collector issue. * The CPM (and Zope's HTTP Cache Manager) must set cache headers only based on the object that generated the (complete) response entity and not based on other objects called during the request (and probably only responsible for part of the entity). As mentioned in my reply to your collector issue, there are fixes on the CMF trunk already and you should look at those to see if they fix your problem. As I replied in the collector: I improves the state of affairs a lot but it still only a partial solution... -- Dieter ___ 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] [Warning] Danger from Zope caching, especially the CMF Caching Policy Manager
Wichert Akkerman wrote at 2006-12-18 08:38 +0100: Previously Dieter Maurer wrote: The description indicates in what direction the CPM should get fixed: * If the response already provides cache control, the CPM should not override it, as it is likely that the specific information available to the response generating process is more trustworthy then the general CPM policies. If we want to make CPM smarted wouldn't it make more sense to have it select the most restrictive set of caching settings? Yes, that is something, I called intelligent merging. -- Dieter ___ 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: [Warning] Danger from Zope caching, especially the CMF Caching Policy Manager
Miles Waller wrote at 2006-12-18 12:57 +:
...
At the moment, the CPM fires after rendering, so setting it's own
headers and overwriting any headers set in the template. If it fired
before rendering, then a template would be free to set whatever policy
it wanted.
Is there a special reason why it needs to set the headers after
rendering, rather than before? I can't think of a reason, but then our
policies are about as simple as can be.
I expect this was to counter the effect that recursively called
templates could trigger the CPM as well. If the CPM is activated
before the actual rendering, then these recursive activations
would override the effect of the top activation.
The latest CMF version tries to detect recursive activations
and suppress them. Nevertheless, your proposal would not be
safe, as shown this this example:
You have a script someScript with the following body
container.REQUEST.response.setHeader('Cache-Control', 'no-cache')
...
context.someTemplate(...)
then the call to someTemplate may override the Cache-Control
set before, even with your proposal.
Of course, the script could set the header after the template call --
*IF* it were aware of the danger. However, I doubt that this will be the
case
--
Dieter
___
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 2.1] FSPageTemplate Unicode
Martin Aspeli wrote at 2007-1-6 22:06 +: Hanno Schlichting wrote: The idea is to use a specialized persistent component registry, that does the needed AQ-wrapping. This will however only give us AQ-wrapped local utilities, whereas those registered with the global component registry wouldn't be wrapped. I think this might be an acceptable trade-off. Are you sure? Does *every* local utility want an aq wrapper? Some of them want (e.g. the Catalog and the proposed ISiteRoot utilitiy). Thus, it is easier (for all of us) when all utilities with an __of__ method are wrapped. I'm not even sure if tools that are well-written (do not rely on acquiring things from 'self') need to do so except for security when called TTW, in which case getToolBy(Interface)Name will do the trick. Bluntly adding acquisition like this seems like a step in the wrong direction, imho. Currently returned tools (via getToolByName) are acquisition wrapped. I think this should stay this way. In Zope 2, non acquisition wrapped objects behave very strangely. E.g. most OFS.Traversable.Traversable methods no longer work correctly; and (as you already noted) security fails. In my view, this indicates that all objects with __of__ method should be correctly acquisition wrapped. -- Dieter ___ 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 2.1] FSPageTemplate Unicode
Hanno Schlichting wrote at 2007-1-7 23:42 +0100: Thus, the proposal exhibits an essential example that local utilities should be returned acquisition wrapped (if the have an '__of__' method). Maybe a compromise would be to only return those utilities back acquisition wrapped that where registered as tools? Why? When an object implements __of__, this indicates that it is willing to play with the ExtensionClass context feature (usually used for acquisition). Why can we not use this indication? -- Dieter ___ 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 2.1] FSPageTemplate Unicode
Martin Aspeli wrote at 2007-1-7 23:40 +: ... Why not do it a more Zope3 ish way: class ICMFTool(Interface): Marker for any CMF tool and then in the subclass of the local component registry: local_utility = if ICMFTool.providedBy(local_utility): local_utility = local_utility.__of__(context) or so. No need to invent a new marker interface for this. Objects ready to participate in context wrapping indicate this by the __of__ method... -- Dieter ___ 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 2.1] FSPageTemplate Unicode
Martin Aspeli wrote at 2007-1-9 20:48 +: - It's an explicit declaration of support As is the definition of __of__. Well, not in a formal sense. I could have some non-Zope python object that I wanted to register as a local utility (to override a global one, say) that could have __of__() for some other reason. Theoretically, you might be right -- but not practically in the ExtensionClass based environment of Zope 2. There you have: if an object has an __of__ it is used for context wrapping -- as soon at it happens to be accessed as attribute of an ExtensionClass instance. In this environment, it is more homogenous and natural to just wrap with __of__ when it is present than looking for an additional marker interface. ... I doubt it matters in this case (I'd guess __of__() is not a very common method name outside Zope, and this would be pretty localised code)... More precisely, __of__ has special (documented) meaning for ExtensionClass. - It may not be desirable to wrap everything that *could* be wrapped. ... What if the method wasn't __of__() but get_size() or something in a different context? I think, I would not have argued about automatic get_size wrapping -- unless it were so common as ExtensionClass's __of__ wrapping. -- Dieter ___ 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: Adding python packages to ProductsPath
yuppie wrote at 2007-1-23 18:55 +0100: ... Yes, I object. This is a hack that resolves the issue just for some special use cases. We need a solution that works with python packages anywhere in the python path. And packageresources (http://www.handshake.de/~dieter/pyprojects/packageresources.tgz; can show a way to do it. An alternative could be the upcoming egg's support for egg local resources. With packageresources a python package/module is identified by an url of the form pypackage:module_path, e.g. pypackage:Products.CMFCore or pypackage:Shared.DC.ZRDB.DA. A resource (e.g. a file or directory) local to a package is identified by an url pypackage:package_path/package_relative_file_path, e.g. pypackage:Products.CMFCore/skins As you can see: this allows to specifiy location independent skin directories. -- Dieter ___ 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] Removing ancient LoginManager-compatibility code
Jens Vagelpohl wrote at 2007-3-12 10:11 +0100: There's some LoginManager compatibility code in CMFCore.MembershipTool (see __getPUS and addMember) that I would like to remove. LoginManager has gone the way of the Dodo several years ago, I'd say at least 4 years ago. IMHO with this stuff there is no need for a deprecation period. Comments or suggestions? Silence is consent ;) I often wonder whether you do not have more pressing tasks :-) Me would never come to the idea to do such cosmetic changes... -- Dieter ___ 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] Derived Content Types WebDAV
Charlie Clark wrote at 2007-3-27 13:28 +0200: having made my own content type which is derived from Document with three additional attributes, I've moved onto the exciting world of editing content via webDAV. It seems some methods have to be extended/ overwritten for this to work so I have added customised versions of the following getMetadataHeaders() # Document.py setMetadata() # Document.py getMetadataHeaders() # DublinCore.py _editMetaData() # DublinCore.py Is this a correct assumption? I would be quite surprised if these methods had much to do with WebDAV editing. Instead, I would look for PROPPATCH (and how it is implemented). -- Dieter ___ 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: Delete trouble
Philipp von Weitershausen wrote at 2007-3-28 08:16 +0200: ... What makes you think you can make that assumption? This is Zope 2 all over again, where things just have to be there. That won't help making things more flexible. Hiding exceptions (or avoiding them at all costs) might be seen as more flexible -- but this approach caused several quality problems in Zope 2. We have this situation here: there should be (and is) a unique id tool but the local registrations have not been performed. Nope, we're just not operating in a place where we can get to the tool. It's standard acquisition semantics. With standard acquisition semantics, you get an AttributeError when the object is not there. You propose something similar (okay, a bit less drastic) to silently ignoring the AttributeError. I argue that (in general, there are exceptions) we should get the exception. An exception is better than silently omit the update of the existing unique id tool. You could argue that the local id tool does not need to be updated as the complete site (including the tool) gets deleted. Indeed. But would the effect be different, if I used: plone_site.some_folder.manage_deleteObjects(). Or in other words, is attribute lookup entailed in traversal? No. If it is not (which I assume), then your defensive programming would hide inconsistencies in the unique id tool -- similar to a defensive try: except: pass. What kind of inconsistencies? We're deleting the thing anyway, what's the point to update it? If you carefully look at the example, it no longer deletes plone_side (and its unique id tool) but something below plone_side. Therefore, consistency of the unique_id_tool may be an issue (it is not deleted and would know about an object with no longer exists). -- Dieter ___ 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] unresolved site manager related issues
Alec Mitchell wrote at 2007-4-12 06:59 -0700: ... ... deprecation of getToolByName ... which is that there's no practical reason other than aesthetics to deprecate getToolByName at this point. A very good point: let's deprecate deprecations done just for aethetical reasons :-) This still seems like we're creating a lot of developer pain with minimal benefit (tools already allow for local customization by acquisition). for precisely this reason. -- Dieter ___ Zope-CMF maillist - [EMAIL PROTECTED] 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] unresolved site manager related issues
Martin Aspeli wrote at 2007-4-15 16:45 +0100: ... Aesthetics were not the original reason for moving down this route, so it's a little unfair to cast it in that light. The main drivers, as I recall, were to encourage API usage that would allow us to move tools out of content space eventually Probably, I do not understand content space. At least, I do not understand why you want to get tools out of it. Most CMF tools are location specific configurations (catalog, skins, actions, types, ...) with a bit of functionality. I do not see a big gain in implementing them as local utilities rather than their current implementation. and to make code depending on CMF tools more consistent with newer code which may depend on new utilities (at least in the Plone world, there is a general consensus that we'd rather not have any more content-space tools from now on). Hm: is their really that big a difference to call getToolByName or getUtility? -- Dieter ___ 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] unresolved site manager related issues
Martin Aspeli wrote at 2007-4-25 19:58 +0100: ... If the root of your CMF/Plone site contains content items, they need to avoid collision with magical objects that are there primarily to make our lives easier as programmers (since you can acquire them, and they interact with Zope security easily, and they give a somewhat simple place to hook configuration UI into, and they give a somewhat simple place to stick configuration data). Most CMF tools are location specific configurations (catalog, skins, actions, types, ...) with a bit of functionality. I do not see a big gain in implementing them as local utilities rather than their current implementation. I'd like them not to be there as attributes/keys/ids of the portal. In Zope 3, this is solved by using namespace traversal adapters giving access to persistent components only under a special namespace (++etc++site). That looks like a trivial naming convention you could use in Zope 2, too: Forbid ids with a special naming pattern for the ids of your content objects and use this naming pattern for your magic objects. -- Dieter ___ 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] reindexObject updates modification time?
Darryl Dixon - Winterhouse Consulting wrote at 2007-5-28 22:30 +1200: Which lends even more weight to my original query - why on earth does reindexObject() update the modification time? I can see utterly no reason why it should... When the object is changed, the modification time should be reset. Now, there are many many ways to change an object. The author of the above hack reasoned: When an object is changed then not only its modification time should be changed but the object should also be reindexed. Reindexation is only one place. Therefore, he implemented modification time update in the reindexObject method. Soon it became apparent that it is not good to change the modification time whenever reindexObject is called. Therefore, the change was limited to called of reindexObject with an empty set of indexes (i.e. all indexes should be updated). I do not say that I like the reaoning or the current state. But, at least, this is the historical cause. The author has discussed the solution on zope-cmf and nobody objected earnestly. That's why I know the reasons and the history. -- Dieter ___ 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] is there a conflict error resistent index
Joachim Schmitz wrote at 2007-6-16 13:35 +0200: ... during our recent search for the cause of the many conflict errors, we discovered that nearly all of them where caused during indexing the portal_catalog, when the same values are indexed. This can happen easily with date_indexes, since the dates are only stored with a resolution of 1 minute. Usually, this will not cause a conflict -- only when in addition the first objects that use a new date value are created in concurrent transactions. I expect that the probability is not too high for this Even more conflict error prone is the reviewstate. Since there are only a few reviewstates. Again, only the initial filling of the document list for a given state is critical. Once there is a document list, this list (an IITreeSet, usually) can concurrently add elements (using application specific conflict resolution -- reducing the conflict probability by a factor of about 120). For one of our internal projects, I have created a set of conflict reduced indexes. These indexes do not delete a document list one it has been created. However, it turned out that this additional conflict protection is not worth the effort. My special indexes have been phased out meanwhile -- Dieter ___ 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/2.1/C - changed the way skins are set up, using __before_publishing_traverse__ instead of __of__
yuppie wrote at 2007-6-18 11:29 +0200: ... Please let me know if you think this checkin causes too much trouble and should be reverted. We are using portals and their skins widely in scripts executed outside of Zope. Especially, they do not use the ZPublisher to traverse to the objects but use more direct methods (which do not look for __before_publishing_traverse__). Your change will break all these scripts -- Dieter ___ 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] is there a conflict error resistent index
Perry wrote at 2007-6-18 13:56 +0200: ... I didn't find any application specific conflict resolution in the fieldindex ? Are you saying, that once there is one document created within a review_state, conflict errors for that review_state are very unlikely, even under heavy load. Yes. Due to the conflict resolution in IITreeSet (which is used to hold the document id list belonging to a given review state). FieldIndex does not need to have its own conflict resolution as the IITreeSet handles most on the document id set level. -- Dieter ___ 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] Design approach questions: unique content-ish items?
Doyon, Jean-Francois wrote at 2007-9-17 15:10 -0400: ... But, its more generic purpose is essentially as a utility for the site, at least conceptually. The only difference might be that it's NOT placeless. But utilities for a site have a natural location: the site root. A utility you place deep inside the site are not utilities for a site but utilities for part of a site. -- Dieter ___ 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: [Zope3-dev] Re: Known working sets II [was: Eggification redux]
Martijn Faassen wrote at 2007-9-25 17:22 +0200: ... Should we then encourage everyone to hardcode version numbers in their setup.py's dependencies list? I think this goes against building applications from components -- as it drastically increases the probability of conflicts. Components should are week dependancy requirements to be maximally usable -- not fixed dependancies. I think, this holds for frameworks, too, as they are also components. -- Dieter ___ 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] Controlling permissions for actions
Charlie Clark wrote at 2007-9-27 21:33 +0200: ... I'm used to restrictions in the ZODB: I usually put these kind of things in a folder with I then restrict. Can you tell me more about metadata? I always look at the unit tests for the syntax: .../CMFCore/tests/fake_skins/fake_skin/test6.py.metadata -- Dieter ___ 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] howto avoid loading of datetime-objects when accessing a portal_catalog brain
Joachim Schmitz wrote at 2007-10-19 10:03 +0200: If one iterates over the result of a portal_catalog search, for each brain there are about 8 datetime objects loaded (one for each dateindex), which quickly fills the memory. how can I access only the brain id You can get the brain id via brain.getRID(). While it would not be necessary in principle (the rid is not part of the meta data tuple) I am not sure whether access to the rid nevertheless loads the tuple (and thereby your DateTime objects). But you can access the rids avoiding the brains altogether: The usual catalog result is a Products.ZCatalog.Lazy.LazyMap instance. Its _seq attribute (obviously private) contains the sequences of rids corresponding to the query hits. -- Dieter ___ 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] Move CMF collector to Launchpad (redux)
Jens Vagelpohl wrote at 2007-10-25 12:37 +0200: ... I personally had one remaining issue, namely the fact that my main browser (OmniWeb) could not display Launchpad at all due to a CSS bug in OW itself. I still have a similar issue: in my browser (Mozilla 1.5), launchpad pages are unreadable: almost the complete page is covered by red signs of the form --\. -- Dieter ___ 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] Move CMF collector to Launchpad (redux)
Andreas Jung wrote at 2007-10-27 21:01 +0200: ... I still have a similar issue: in my browser (Mozilla 1.5), launchpad pages are unreadable: almost the complete page is covered by red signs of the form --\. You can solve this by upgrading to a more recent browser. But, I probably will not use Launchpad instead -- Dieter ___ 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] change ownership on Zope objects
Marie Robichon wrote at 2008-2-6 08:42 +0100: One of the administrators of our Plone site has changed services. Given that our user authentication is via LDAP and that this person has write access to some parts of our site I now want to change the ownership of the pages he created in order to remove his write access. Ownership is managed with methods in AccessControl.Owned.Owned. Note, however, that its use is restricted. Its sole purpose is to help against trojan horse attacks and it affects only executable objects (scripts, templates). The Owner role (it affects permissions on objects) is a local role managed with methods in AccessControl.Role.RoleManager. -- Dieter ___ 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: What is the status of GS wiping catalog indexes on catalog.xml import?
Andreas Jung wrote at 2008-2-28 07:13 +0100: --On 27. Februar 2008 21:59:58 + Maurits van Rees [EMAIL PROTECTED] wrote: greenman, on 2008-02-27: So, for the catalog.xml importer, why can't the trigger for reindexing an index be a flag on the catalog index declaration itself? Is it really generic setups role to determine if changes to an index invalidate the values it already holds? If you were to change properties of an index through code and not GS, then it would be up to you whether you reindexed all your objects or not. The problem is that GenericSetup does not know if your current index is of the same type and has the same settings/properties as the index that you specify in catalog.xml. Apparently it is hard/impossible to reliably compare the existing and the wanted index. So GenericSetup has no choice but to remove the existing index and make a new one. How about the following idea: - within the Zope core we define an _optional_ interface for indexes - something like: class IIndexConfiguration(Interface): def getConfiguration(): Returns a dict with index specific configuration parameters. - on the CMF/GS side we could register adapter for each index type we know (basically the Zope 2 core indexes, ExtendedPathIndex, TextIndexNG 3) and retrieve the related information I do not understand why something like this should be necessary. When the export handler is able to extract all relevant configuration parameters for an index, why should the import handler not be able to check the configuration parameters in a profile against an existing index and determine that it needs to do nothing? -- Dieter ___ 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: What is the status of GS wiping catalog indexes on catalog.xml import?
Andreas Jung wrote at 2008-2-29 06:43 +0100: ... When the export handler is able to extract all relevant configuration parameters for an index, why should the import handler not be able to check the configuration parameters in a profile against an existing index and determine that it needs to do nothing? Huh? Because we're looking for a clean solution and not for a hack! Why is it a hack when the import handler uses as much detail about an object as the export handler does? As I understood Wichert, we can currently export indexes reliably but we cannot import it without removal and recreation of the index. I cannot understand this. -- Dieter ___ 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] How does Zope know the name of the session cookie it should refer to?
Alex Man wrote at 2008-4-8 13:37 -0700: My apologies if this isn't the correct mailing list I should post this question to. Please let me know if I should post on another list. I'm using Shibboleth as the authentication system in Plone Maybe, the Plone mailing list might be better. and is wondering how Zope knows the name of the session cookie it should refer to. Zope calls the session id browser id (do not ask) and manages (configures) it in its browser_id_manager. -- Dieter ___ 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] CMFCore badly registered on PyPI
I tried to easy_install CMFCore from PyPI -- this failed. Apparently, CMFCore is only registered on PyPI, not uploaded (this is okay). Moreover, the url registered as home page (http://www.zope.org/Products/CMFCore;) apparently does not exist. I do not think that this is a good sign... -- Dieter ___ 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] [GenericSetup] easy_install reports SyntaxError
easy_installing the current PyPI version of Products.GenericSetup (1.4.0) reports: File /home/dieter/z211/z11python/lib/python2.4/site-packages/Products.GenericSetup-1.4.0-py2.4.egg/Products/GenericSetup/doc/SampleSite/profiles/default/siteroot/bar.py, line 22 return printed SyntaxError: 'return' outside function -- Dieter ___ 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.intid and DirectoryView
Ross Patterson wrote at 2008-6-30 10:34 -0700: ... Creating a savepoint seems to do the trick: from persistent import Persistent import transaction app.pob = Persistent() app.pob._p_oid is None True s = transaction.savepoint() app.pob._p_oid '\x00\x00\x00\x00\x00\x00E\xfa' Would that be a problem causing ZODB bloat? savepoint does not write to the main storage. The main storage is only modified after the final commit. -- Dieter ___ 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] CMFActionIcons vs. new-style actions
yuppie wrote at 2008-9-18 11:13 +0200:
...
I personally prefer to move all type info Actions to the actions tool. I
can't see a need to specify separate 'view', 'edit' or 'metadata'
Actions for each content type. That just makes it necessary to maintain
a lot of redundant configuration data. In how many places did you have
to set string:${portal_url}/edit_icon.png?
Not all of my content types have all actions from view/edit/metadata.
Some of my content types have two different view actions (one
which shows the metadata and one which shows the content).
--
Dieter
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] 'add' actions and views - a proposal
yuppie wrote at 2008-9-21 13:48 +0200: ... Proposed CMFCore TypesTool changes -- 7.) listActions of the types tool returns add actions for *all* portal types. +1 - this change is already done, right? Yes. Checked in yesterday. But hopefully, the different add actions can be grouped easily. We have portals with many dozens of add actions and do not want to present them on a single page (but have them grouped on several pages according to foci -- we are currently use appropriate categorys for the grouping). -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] MembershipTool: Using traversal to look up the Members folder?
Jens Vagelpohl wrote at 2008-10-8 14:57 +0200: ... As far as the feature itself is concerned, I've never seen a situation where this is useful or needed. As so often -- we need it :-) Our MembershipTool instance is (together with the portal) in a read only mounted storage while the Members folder obviously has to be in a read/write mounted storage. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] MembershipTool: Using traversal to look up the Members folder?
Jens Vagelpohl wrote at 2008-10-11 09:21 +0200: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 11, 2008, at 08:16 , Dieter Maurer wrote: Jens Vagelpohl wrote at 2008-10-8 14:57 +0200: ... As far as the feature itself is concerned, I've never seen a situation where this is useful or needed. As so often -- we need it :-) Our MembershipTool instance is (together with the portal) in a read only mounted storage while the Members folder obviously has to be in a read/write mounted storage. As so often, you have never mentioned that this is useful or needed ;-) I did -- in the message you have reponded to ;-) I did this to support Raphael's extension request. For us, there was no need to change CMFDefault (which we do not use at all) nor CMFCore. Instead, we implemented the additional flexibility in a class derived from CMFCore.MembershipTool.MembershipTool. Seriously, I know you may have some use cases that few of use will ever see or need, but if there's no feedback at all then it's not possible to consider them. Sure. And my response had not the intension to blame the CMF developpers why a much needed feature is still not available but only to threnghen Raphaels request for a minor extension :-) If you have a fully-tested patch I'll be happy to look at it. As I understood, Raphael has one. I do not as we have a separate MembershipTool (only derived from that of CMFCore). @Raphael: I suggest to put the extra flexibility into CMFCore (and not only into CMFDefault). -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] Should portal_setup be registered as utility?
Wichert Akkerman wrote at 2008-11-17 08:21 +0100: ... I'm sure CMF import/export steps are fine. The CMF tools are not, and third party products use those in their steps. That is exactly the problem we where seeing in Plone, and which is why I removed the utility registration. Zope is a Web application framework. Obviously, the request is quite important for many tasks related to Web processing. Zope3 may have other, cleaner ways to access the request. But Zope2 has just two ways -- explicit passing and request access via the acquisition context. Thus, why do local utilities registered by Five (i.e. these utilities are for Zope2 use) do not provide access to the request in the normal Zope2 way? If they would, local utilities were much nearer to tools and the transition would be facilitated. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] Should portal_setup be registered as utility?
yuppie wrote at 2008-11-18 12:00 +0100: Dieter Maurer wrote: Thus, why do local utilities registered by Five (i.e. these utilities are for Zope2 use) do not provide access to the request in the normal Zope2 way? That's what we tried first. But it turned out that Zope 3's site manager code caches the utilities across request boundaries. AFAICT it would have been necessary to rewrite the registry code completely to make sure we return always the right request. If they would, local utilities were much nearer to tools and the transition would be facilitated. They would be nearer to tools, but also more distant from zope 3 utilities. I doubt that would really be a win. Then, maybe, Zope 3 utilities are inadequate at many places in to Zope 2 world: e.g. any tool that uses TALES expressions may want to access the (current, of course) request -- especially when they are destined for user interaction (as actions are). In view of this, one can understand that Plone has problems with the setup_tool utility registration. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] Should portal_setup be registered as utility?
Martin Aspeli wrote at 2008-11-18 16:25 +: ... This won't solve this particular problem, but it may be worth looking at how other frameworks work. Pylons, for example, has the request available as global variable - actually a thread-local. Zope could set the request as a thread local in the same way that it sets the site manager (so you can get it via getSite()). Calling getRequest() would in many ways be cleaner than doing self.context.REQUEST or whatever, and would work regardless of whether the context was acquisition wrapped. That, too, would be a solution to access the often needed request -- just not the typical Zope2 one: i.e. lots of rewrites would be necessary. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] Should portal_setup be registered as utility?
Charlie Clark wrote at 2008-11-20 20:33 +0100: ... Agreed. If third party tools have problems, then they should provide the solutions. The Plone people are much more open to integrate third party solutions (a good thing in principle). But, they have only limited control over third party solutions. Therefore, they changed their CMF version to give third parties more time to adapt to a more Zope 3 style of doing things (e.g. accessing request only on code paths specifically designed for request processing). Note, that not everybody finds a more Zope 3 style of doing a worth in itself -- with corresponding reluctance to change something just for this purpose. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF write performance as poor as Plone?
Andreas Jung wrote at 2008-11-21 07:31 +0100: ... write performance ... However the transaction size does not seem to have any impact on the number of simulataneous writes. Have you profiled an individual request to learn what the time is spent for? If the time is dominated by client side activity, you need client side skaling to increase the throughput significantly. If, on the other hand, the time is heavily dominated by server side activity, you would need backend skaling (which is currently quite difficult to get) or get the backend significantly faster (I assume that the bandwidth is not the limiting factor). -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF write performance as poor as Plone?
Andreas Jung wrote at 2008-11-23 09:24 +0100: ... Have you profiled an individual request to learn what the time is spent for? If the time is dominated by client side activity, you need client side skaling to increase the throughput significantly. If, on the other hand, the time is heavily dominated by server side activity, you would need backend skaling (which is currently quite difficult to get) or get the backend significantly faster (I assume that the bandwidth is not the limiting factor). This issue is independent of the client-side. ab2 and cmf/plone were running on the same (fast) machine. The other responses you have gotten indicate that client side activity (especially indexing) can significantly influence the observed write performance (going down by one order of magnitude). That means: it might be worth to check explicitely that this is not the case in your setup. If indexing is suppressed/delayed (as indicated in the other responses), the number of store operations also decrease. Each store operation may account for a few ms (I have observed a general ZEO overhead of about 3 ms -- however some years ago and therefore on an older hardware geneation; things may be faster nowadays). Looking at the number of your stores (and the time they take), you may check whether this may account for the pure write performance you observe. In this case, optimizations would be possible. In principle, the stores could be batched rather than transmitted individually (of course, this would require ZODB modifications). -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] adding 'context' as an alias for 'object' in action expressions
Ross Patterson wrote at 2008-11-30 11:25 -0800: ... I'm not really up on the historical considerations, but I'm definitely in favor of context and definitely opposed to object. object is too generic, the request is an object after all, everything is an object. context reads more like what it is. +1 Of course, it should be consistent (as Yuppie noted), i.e. context everywhere (the same way in scripts, views, actions, templates, ). -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Charsets
Charlie Clark wrote at 2008-12-14 12:32 +0100: Am 13.12.2008 um 18:40 schrieb Charlie Clark: Hi, I'm struggling with the way formlib forms handle decoding from forms. It looks like this gets set in BrowserView using an IUserPreferredCharsets adapter. The default adapter seems to be in zope.publisher.http and it looks like latin-1 will be set if there is no other charset and I'm having problems with the em-dash and en-dash (u'\u2013' and u'\u2013') characters automatically being converted from latin-1 when they are being entered as cp1252. For content that doesn't through this decoding I have no problems if zpublisher- default- encoding is set to cp1252 and the default_charset is set to cp1252 as well: decoding with CMFDefault.utils.decode() works just fine. I suspect I'm missing something basic in the way charsets are handled but as it's a windows only IE6 environment, is the easiest solution writing an adapter that defaults to cp1252 if there is no HTTP_ACCEPT_CHARSET in the request header? Overriding the adapter works fine. I'm still a bit confused by the original code: It is usually insane to use client preferences to guess the encoding used in form data. Usually, the client will use the charset it has found in the page containing the form. Thus, unless this charset has been determined automatically from the Accept-Charset header, it is merely accidental when the client preferences (Accept-Charset) is able to guess the charset correctly. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Charsets
Charlie Clark wrote at 2008-12-19 11:35 +0100: ... Usually, the client will use the charset it has found in the page containing the form. Thus, unless this charset has been determined automatically from the Accept-Charset header, it is merely accidental when the client preferences (Accept-Charset) is able to guess the charset correctly. Right. So I must be doing something wrong if all Zope has to go on for decoding the form is the Accept-Charset? How can I set an encoding for the form? The site should deliver all pages containing forms (if possible even all pages) with a single charset, let's call it the site charset. Then it uses this same charset to interpret form data. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Cleaning up imports, question about odd feature
Charlie Clark wrote at 2008-12-30 13:17 +0100: Am 29.12.2008 um 19:20 schrieb Tres Seaver: As Jens noted, this change is for FSProperties and FSSQLMethods only. Yep, and these aren't generally objects that need to be changed frequently in the FS. But if possible, all FS* objects should behave identically with respect to debug-mode on. It should not be the case that, e.g., FSPageTemplate is reread in debug mode but FSProperties is not. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Charsets
Charlie Clark wrote at 2009-1-18 15:49 +0100: ... I would suggest that we work towards enforcing UTF-8 in where possible but at the very least add the accept-charset attribute to forms and use the portal's default_charset for this. I'd very much appreciate your comments on this. The Accept-Charset request header should *never* be used to guess a charset at the server side: Accept-Charset is a user preference which does not know anything about charsets used by the server. If utf-8 would not be treated with preference in the current code, the code base would see massive problems. Only the server knows which charsets it is using -- and it should use a single one (with very few exceptions). There should be a configuration option that tells this charset and this should be used to decode form data. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Charsets
yuppie wrote at 2009-1-19 11:32 +0100: Charlie Clark wrote: Am 18.01.2009 um 23:00 schrieb yuppie: I agree that there shouldn't be implemented in a different way than for Zope 3. And if we can solve the problems by fixing form encoding I'm happy. Although I'd like to see UTF-8 always the first charset returned if * the quality is the same. zope.publisher.http.HTTPCharsets explicitly prefers utf-8. Are you sure getPreferredCharsets()[0] is iso-8859-1 with your browser? This might be true for the Zope 3 publisher however, Zope 2 HTTPResponse uses default_encoding (configured in zope.conf) unless an encoding is prescribed by the response content type -- and this has nothing to do with the Accept-Charset request header. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Charsets
Charlie Clark wrote at 2009-1-18 22:30 +0100: Am 18.01.2009 um 20:36 schrieb Dieter Maurer: ... From the current HTML specification: accept-charset = charset list [CI] This attribute specifies the list of character encodings for input data that is accepted by the server processing this form. The value is a space- and/or comma-delimited list of charset values. The client must interpret this list as an exclusive-or list, i.e., the server is able to accept any single character encoding per entity received. ie. exactly as you have suggested: it is possible to force a client to encode data in a particular charset before sending it to the server. All references I have come across suggest that this, together with the meta tag content-type can and should be used to coerce browsers to use UTF-8. I fear that the accept-charset form control attribute can easily only be used for method=post content-type=multipart/form-data as only then the browser has a chance to specify how it has encoded the value. I am not sure whether Zope handles the charset information in this case correctly. As the Accept-Charset request header has (almost) nothing to do with the accept-charset form control attribute, it must of course not be used to interpret form data even when this was created based on an accept-charset. If the server chooses its output encoding based on the Accept-Charset request header (and Yuppie indicated that the Zope 3 publisher does this), then the same algorithm can be used for normal form data (where normal means, you do not explicitely specify an accept-charset form control attribute). That's one sensefull mode of operation. Another one is choosing a fixed encoding and using it as input and output encoding. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Charsets
yuppie wrote at 2009-1-19 22:54 +0100: ... Products.Five.browser.decode.setPageEncoding sets the response content type charset based on zope.publisher.http.HTTPCharsets. And setPageEncoding is called by the update method of formlib forms in Zope 2. So in this case the response encoding has something to do with the Accept-Charset request header. Wow. Some magic in formlib deviating from the Zope2 standard behaviour But, if this is true, we do not understand Charlie's observations: When I understood him right, he is using formlib and he is observing problems with the charsets. He found out that this has to do with IE browsers sending an empty Accept-Charsets header which is turned by Zope's preferredCharset into iso-8859-1. But when the same charset is used on both form delivery and on form processing he should not see a problem with mismatched encodings. Of course, iso-8859-1 may not be approriate for form delivery -- and may result in funny special characters in non-western countries. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] five.localsitemanager: dependencies
Charlie Clark wrote at 2009-2-14 16:22 +0100: ... I'm not that familiar with Buildout but I would have thought that any direct import dependencies should be listed - and zope.location doesn't seem to be (neither are zope.event or zope.site for that matter). OTOH the condition = seems to be being incorrectly interpreted. If this is a bug then it should be filed. You are right, but unfortunately this is quite a deep problem in setuptools. setuptools does not determine the complete dependancy graph and then looks for a global solution to the set of restrictions. Instead it satisfies restrictions incrementally thereby committing some versions -- and may later find that they conflict with other requirements. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] five.localsitemanager: dependencies
Tres Seaver wrote at 2009-2-14 20:31 -0500: ... For all its flaws, setuptools fixes a lot of what is horribly broken in distutils: most of the flaws arise from the choice to stay pseudo-compatible with distutils, and reuse it, rather than starting from scratch. But the dependancy handling is obviously introduced by setuptools. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [Checkins] SVN: Products.CMFCalendar/trunk/setup.py - dependency cleanup
Jens Vagelpohl wrote at 2009-2-16 13:48 +0100: ... Does anyone else have a specific opinion for this case, disregarding the five.localsitemanager discussion? Dependancies should be as loose as possible. If a component uses CMFDefault but only indirectly CMFCore, it should specify CMFDefault as a dependency but not CMFCore. If it explicitely uses both CMFDefault as well as CMFCore, specifying both may be more future proof. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
