[Zope-CMF] Re: CMF collector on Launchpad?
On Mon, 13 Aug 2007 01:49:36 -0700, Hanno Schlichting
<[EMAIL PROTECTED]> wrote:
I'll dare to speak out the unthinkable and as an alternative option
suggest to move the CMF bug tracker to a trac instance hosted on
plone.org.
As another piece of info (I'm not +/-1, as I rarely use the CMF collector,
and it works for me), we have a script that is capable of doing the
CMFCollector -> Trac migration, if that should be on the table in any
variation. Our Bug #1 still exists in Trac:
http://dev.plone.org/plone/ticket/1
("Opened 5 years ago" indeed — quite a bit before Trac existed :)
--
Alexander Limi · http://limi.net
___
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: Effective Date inconsistencies
On Sun, 24 Jun 2007 06:33:28 -0700, Tres Seaver <[EMAIL PROTECTED]> wrote: - -1: anybody who is using the string representations for comparison is mising the point: those values are "display only." they should be using the forms which return real datetime obojects. Yeah, I wasn't arguing for changing the DC element accessors, I know those should be strings. The ceiling / floor date bits are there to support indexing / sorting, and therefore comparison. We could tackle this by adding an argument, 'use_ceiling' / 'use_floor' to those methods, defaulting it to True for this release, and then switch the default and add a deprecation warning in the next release. Or we could add new APIs, e.g. 'effectiveOrNone', 'expiresOrNone' and leave the current methods alone. If you want to talk about remonving those bits, you still have to deal with special casing the bits where the content object has a real None value. For indexing, we can use the support provided already by DateRangeIndex for handling "open" intervals (the real case that the floor / ceiling were meant to handle). OK, I just wanted to compare two dates like I do in Python, and display a result accordingly. So would the "correct" thing to do here make it support None as a return value, but switch to DateRangeIndex? -- Alexander Limi · http://limi.net ___ 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: Re: Effective Date inconsistencies
On Sat, 23 Jun 2007 04:34:37 -0700, Charlie Clark <[EMAIL PROTECTED]> wrote: If it returns a __FLOOR_DATE then you can easily write your own comparison to create a boolean. has an effective date and was modified afterwards Wonderful, then my template code depends on some variable defined in the code as the floor date as a private variable, meaning I shouldn't introspect it. Very robust. ;) -- Alexander Limi · http://limi.net ___ 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: Re: Effective Date inconsistencies
On Sat, 23 Jun 2007 08:15:02 -0700, Wichert Akkerman <[EMAIL PROTECTED]> wrote: Previously Laurence Rowe wrote: How about changing EffectiveDate to: return ed and ed.toZone(zone).ISO() or '' from the existing (as pointed out by Charlie): return ed and ed.toZone(zone).ISO() or 'None' It would seem the least risky fix. (I'm not sure it's strictly a bug but it struck me as completely brain dead when I was caught out by it). We can't change it - people may rely on the current behaviour. Which I why I ask here, people that may rely on this are likely to be on this list (and able to speak up about it). The fact that zope.dublincore got it right makes it even more interesting to harmonize them, IMO. -- Alexander Limi · http://limi.net ___ 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: Effective Date inconsistencies
On Sat, 23 Jun 2007 02:55:51 -0700, Charlie Clark <[EMAIL PROTECTED]> wrote: What would you rather have? An attribute error? No, I want a boolean false value. If you wish to compare the values you need to access context.effective and context_modified I already stated that this won't work, it returns __FLOOR_DATE, which makes it useless for boolean operations: def effective( self ): """ Dublin Core Date element - date resource becomes effective. """ marker = [] date = getattr( self, 'effective_date', marker ) if date is marker: date = getattr( self, 'creation_date', None ) return date is None and self.__FLOOR_DATE or date I'd like this one to return False, not some floor value. I understand that the official CamelCase accessors always return strings (which is fine), but I don't see why "effective()" can't give a False value. Is this just historical, or is there a real reason for it? -- Alexander Limi · http://limi.net ___ 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] Effective Date inconsistencies
Hi, I was trying to do a very simple template operation today: 1. Show the Effective Date if it is identical or more recent than the Modification Date 2. Show both Effective and Modification Dates if Modification Date > Effective Date Should be simple, right? Published on […] Modified on […] Not so: - EffectiveDate returns a *string* 'None' when it has no value (wtf?) - Then I think "that's what 'effective' is for" — it return __FLOOR_DATE if unset, so no False there either. There seems to be no way of getting the effective date to actually return a False value. I am forced to crazy conditions like these: tal:condition="python:context.EffectiveDate()!='None'"> and tal:condition="python:context.EffectiveDate()!='None' and context.EffectiveDate() < context.ModificationDate()"> …and then Stefan says "I don't know whole story of your condition, you may need to use == and or or whatever, point being you have to guard for EffectiveDate being 'None'" At which point I want to ask: Can we fix this in CMF 2.1, so it is possible to get False values from the date objects? The current situation seems pretty ridiculous. I might have missed it if there is a better way, but I couldn't find any. -- Alexander Limi · http://limi.net ___ 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: Workflowable folders & traversing issues
On Thu, 07 Jun 2007 05:57:49 -0700, Doyon, Jean-Francois <[EMAIL PROTECTED]> wrote: OK, so which security setting do I set/unset to prevent traversal then? http://plone.org/documentation/how-to/make-folder-hierarchy-private -- Alexander Limi · http://limi.net ___ 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: Problem with STX rendering
On Thu, 10 May 2007 07:28:49 -0700, Charlie Clark <[EMAIL PROTECTED]> wrote: Anyway before I submit a follow-up to the bug is there any CMF setting I can use to avoid this problem? It's a known issue with STX. -- Alexander Limi · http://limi.net ___ 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: Making TypesTool faster
On Fri, 04 May 2007 05:17:36 -0700, Tres Seaver <[EMAIL PROTECTED]> wrote: I think I misunderstood: you guys have actually measured that the 'manage_addProducts[product]' dance is taking measurable time when building the add list? I thought we were trying to cache the result of the whole lookup, especially the meta_type-is-allowed + user-has-permission checks, which I would imagine are much more expensive than the factory dispatcher lookup. Actually, it seems to be — but I'm not a programmer — I just know that when we cached the result of that lookup locally, the whole thing is about twice as fast overall. That's including our metatype-is-allowed and has-permission checks. That said, I didn't really understand the patch as earlier proposed; I'm sorry for not reading more carefully. Did you have time to look at it now? If the two are orthogonal, and we already have a sane patch, then why not (at least if we can get some tests in place) fix the one at the CMF level and deal with the other Archetypes issue separately. If factory dispatcher lookup is truly the hotspot, then we should be fixing it even lower in the stack (at the Zope level). It's just my experience that it's harder to get small optimizations into Zope for these kinds of things, as it's more likely that people rely on side effects like this (the fact that the list of products can change without restarting) there. But if you think it can be done on that level, it would of course be the optimal location to do it. -- Alexander Limi · http://limi.net ___ 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: Making TypesTool faster
On Thu, 03 May 2007 00:33:05 -0700, Martin Aspeli <[EMAIL PROTECTED]> wrote: I feel like we're having a very abstract discussions here. Have you looked at the patch Alec/Ben/Mike/Rob did? If not, Limi - can you find it and paste it here so that we can discuss its merits? I don't recall whether it came with tests, but even so it didn't look terribly complicated. I included it in my initial post, but here it is again: http://paste.plone.org/13211 -- Alexander Limi · http://limi.net ___ 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: Making TypesTool faster
On Wed, 02 May 2007 10:03:39 -0700, Martin Aspeli <[EMAIL PROTECTED]> wrote: +1, but I don't think the two need to be mutually exclusive. Amen. At present, Archetypes-based content types cannot be used with a factory (I tried hard, but there are some acquisition-related/factory related reasons); I'd like to refactor this, but we can't for Plone 3.0 at least. Right. Obviously, we'd like to do this "the proper way", but we can't do that for a while yet. Given that Alec & co essentially had a patch which worked, I suggest that we have a look at it, and include it if possible, and then encourage the use factories in general. I'd hope we could avoid deprecating it outright until we can fix up AT to use them, though. Also note that according to Alec, it would work better as a instance-level thing than a thread-level one. Isn't this something like 2 lines of code in TypesTool? :) -- Alexander Limi · http://limi.net ___ 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] Making TypesTool faster
Hi all, I would like some input on making CMF (and by extension Plone) more efficient. This issue goes back to the original discovery that Zope had a bug that made its Product lookup mechanism be very slow in Zope 2.10.0/1, and affected TypesTool lookups in particular. When we experimented with this during the Performance Sprint at Google, we lowered the call time from 6.26s to 0.29s by caching it in a thread local cache. (All calls and timings are 10 calls to the standard Plone front page on a 2GHz MacBook) The contentmenu.pt template in Plone (which pretty much just does the TypesTool lookup for what types are addable), currently takes up roughly 30% (!) of the total cost of rendering a standard page in Plone. After the bug fix was applied to Zope 2.10.3, the call went down to 0.80s with the same hardware/#calls — there's still a significant potential for improvement here: 0.80s -> 0.29s. Here's what Alec Mitchell wrote about it at the time: """ The fundamental issue is not that product lookup is slow in Zope, but that CMF uses the Product lookup mechanism as a registry without any sort of caching. This is quite easy to fix either in Plone or in the CMF depending on the timeframe we need it merged in for. I initially used a thread local for safety because I wasn't entirely sure what sorts of things would end up in this cache. However, by now it's pretty clear to me that an instance level cache should be perfectly safe, which should be a little faster yet. """ So what I'm wondering is whether it's possible to get this instance-level caching of the lookup in the types tool before CMF 2.1 final? I'd obviously prefer it if Plone didn't have to subclass and override parts of TypesTool to fix this. :) (Oh, and for reference — the original thread local cache that we used for testing is here: http://paste.plone.org/13211 ) -- Alexander Limi · http://limi.net ___ 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: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
On Wed, 18 Jan 2006 09:39:21 -0800, Andreas Jung <[EMAIL PROTECTED]>
wrote:
I agree :-) But I would like to see reasonable feedback from the Plone
community about any problems with 2.9.0 to have them fixed for you in
2.9.1.
Of course. We'd like to be running on 2.9 too. :)
--
_
Alexander Limi · Chief Architect · Plone Solutions · Norway
Consulting · Training · Development · http://www.plonesolutions.com
_
Plone Co-Founder · http://plone.org · Connecting Content
Plone Foundation · http://plone.org/foundation · Protecting Plone
___
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: RFC: backporting including python-package-product support to support Zope 2.8
On Thu, 19 Jan 2006 12:35:20 -0800, Tres Seaver
<[EMAIL PROTECTED]> wrote:
Zope Corp. is willing (or has been, anyway; I can't speak for them any
longer) \to sell support for released versions of Zope. Under such a
contract, the supporting company would arrange to get critical
(stability / security-related) bugfixes backported, if the
version-under-support was no longer the actively developed version.
Anyone expecting to get *that* kind of support for free is smoking
crack, given the size of the Zope community and its general willingness
to upgrade as needed.
Indeed. We also support older Plones/Zopes if we get paid (and backport
fixes), but it's unrealistic to let the community handle this level of
support.
--
_
Alexander Limi · Chief Architect · Plone Solutions · Norway
Consulting · Training · Development · http://www.plonesolutions.com
_
Plone Co-Founder · http://plone.org · Connecting Content
Plone Foundation · http://plone.org/foundation · Protecting Plone
___
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: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
On Wed, 18 Jan 2006 09:20:41 -0800, Andreas Jung <[EMAIL PROTECTED]> wrote: --On 18. Januar 2006 09:03:15 -0800 Alexander Limi <[EMAIL PROTECTED]> wrote: Note that I'm not saying it *won't* ship with 2.9, just that we reserve the right to ship with 2.8, since the 2.9 status is still uncertain, What is uncertain (except the issues with the Windows release)? The Windows release is a big part of what makes Plone interesting to new adopters, so that is the primary one. In addition, I have yet to use a Zope release which didn't have serious problems in its .0 release. I'm not saying this *has* to be the case with the 2.9 release - just being realistic. ;) Can we drop this discussion now? It's getting very repetetive. -- _____ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ 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: RFC: backporting including python-package-product support to support Zope 2.8
On Wed, 18 Jan 2006 00:45:14 -0800, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: Let's put it this way: By the time Plone 2.5 is releases (if according to roadmap), Zope 2.8 is one month away from being *discontinued*. Conservative or not, I wouldn't bet on a release line that won't receive bugfixes the minute I start using it... Note that I'm not saying it *won't* ship with 2.9, just that we reserve the right to ship with 2.8, since the 2.9 status is still uncertain, and since neither the Zope or Plone teams have released anything on the actual date of the deadline so far. I think it's great that we have a somewhat reliable time-based release schedule - but all the kinks are not worked out yet. ;) -- _____ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ 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: RFC: backporting including python-package-product support to support Zope 2.8
On Tue, 17 Jan 2006 16:22:07 -0800, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: From what you're saying I deduct that Plone 2.1 favours Zope 2.7 over 2.8. Below you are suggesting that Plone 2.5 should do the same with Zope 2.8 (favouring it over 2.9). I don't understand why that should be. If one version has to be favoured at all, it should be the most recent one. That way it's made clear that the lower version (2.7, 2.8) is only still supported as a courtesy for those who don't want to upgrade right now. All other Plone developers and users should preferrably use the highest stable of Zope, otherwise Plone will continue to lag behind at least one Zope major release. Well, this depends on what release ships when. We made a decision not to ship Zope 2.8.0 as the standard in the installers when shipping Plone 2.1 - and that turned out to be a good choice, based on the number of problems it had. I can guarantee you that Plone 2.5 will not ship with a Zope 2.9.0. A Zope 2.9.(1|2|3) might be possible, but there's no way we are shipping a .0 release of Zope with Plone. Once burnt, twice shy. :) That and make the upgrade from Zope 2.7/2.8 to 2.9 flawless as well as make 2.9 the *recommended* version for Plone 2.5. Then I don't think it should be much of a problem for Rocky to not have this available in 2.8, except perhaps if he wants to get started right now, with Plone 2.1 (though that might still run under Zope 2.9 and CMF 1.6, I hope). What we ship in installers is one thing, what we personally use and recommend is another. The installers will always be more conservative when choosing versions. Most developers using Plone 2.1 uses it with Zope 2.8, but the installers ship with Zope 2.7, and it turned out to be a good decision in hindsight. -- _____ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ 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: Move GenericSetup out of CMF
On Tue, 17 Jan 2006 07:39:10 -0800, Tres Seaver <[EMAIL PROTECTED]> wrote: I don't think the burden of maintaining 'svn:external' is worse than the burden of maintaining the correct version ID in DEPENDENCIES.txt. I *want* to distribute GenericSetup with the CMF tarball, in fact, which makes 'svn:external' seem the Right Thing (TM). From experience, it's the only thing that *does* get maintained, since people's checkouts break. ;) -- _____ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 2.0 Release Status
On Wed, 11 Jan 2006 20:00:18 +0100, Jens Vagelpohl
<[EMAIL PROTECTED]> wrote:
This ties into the second question, which Plone core developers can
answer better, about the plans for which version of Plone will go with
which version of CMF.
Plone 2.5 (the next release, due this spring) will use CMF 1.6, and I
believe the goal is for Plone 3.0 to use CMF 2.0. I'm not the release
manager, though - status of the latter is still undecided, since it is
still some time away. I assume Zope 2.10 will be out by then.
http://plone.org/roadmap
--
_
Alexander Limi · Chief Architect · Plone Solutions · Norway
Consulting · Training · Development · http://www.plonesolutions.com
_
Plone Co-Founder · http://plone.org · Connecting Content
Plone Foundation · http://plone.org/foundation · Protecting Plone
___
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: Bug when removing state in DCWorkflow
On Thu, 05 Jan 2006 13:07:07 +0100, Florent Guillaume <[EMAIL PROTECTED]> wrote: Tres Seaver wrote: Objects which have a no-longer-sane review_state have *never* had reasonable behavior: the workflow engine *can't* compute what to do with them. They have no transitions (which is why the workflow actions are gone), and they can't be fixed by the "Update Security" button, because there *is no state* to whose permission map they can be conformed. This always worked in earlier versions, and has always been the way to get people who don't know how to script CMF to modify workflows. The rule was simple: "If you remove a state and click the Update Security button, the objects that are in the state that no longer exists will fall back to the initial state". This has stopped working. Whether it was intentional or not, this behaviour was useful, consistent, and exists in a lot of documentation out there, even a few of the Plone books, IIRC. Raphael Ritz wrote: Not really following the topic, so this might be too naive, sorry: Falling back to the workflow's initial state (like it's done on imports and when changing the workflow assigned to a type) in such cases wouldn't be an option? That's what it used to do. It no longer does. Florent Guillaume: That's been the intent of the code all along: when you query the workflow tool and ask it for the state of an object, this is passed along to DCWorkflow, and if the object doesn't have a state anymore the initial state is returned. However if you remove a valid state, nothing queries and recatalogs all the objects, so they still have an old review_state in the catalog. "Update security settings" is for a different use case, I'm not sure it should be retrofitted into doing this. So why did it work in earlier CMF versions? I'm curious. :) The reason why this is so important to me is that it removes the ability for non-developers to do any sort of meaningful change to the workflow. Removing a state and having the objects in that state fall back to the initial state is extremely useful - whether it was intentional or not. -- _ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ 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: Bug when removing state in DCWorkflow
On Wed, 04 Jan 2006 15:27:48 +0100, Florent Guillaume <[EMAIL PROTECTED]> wrote: Alexander Limi wrote: Can anybody familiar with DCWorkflow take a look at this? http://trac.plone.org/plone/ticket/5067 It used to work, and is a classic workflow change operation that I personally use all the time. CMF doesn't have a "workflow pulldown", and has probably different ways of filtering displayed content. Can you configurm that the bug applies to pure CMF? Yes, I can. The issue has several replies, one of which confirms the existence in plain CMF 1.5. There is also a patch from Dorneles to fix this, if any of you could review it, I would appreciate it. -- _____ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ 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] Bug when removing state in DCWorkflow
Can anybody familiar with DCWorkflow take a look at this? http://trac.plone.org/plone/ticket/5067 It used to work, and is a classic workflow change operation that I personally use all the time. -- _ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On Thu, 22 Dec 2005 04:10:30 +0100, Rob Miller
<[EMAIL PROTECTED]> wrote:
it would be great if Plone 2.1.X could work w/ CMF 1.6, but it is not
absolutely necessary.
In general, we consider Plone tied to one particular CMF version (which is
also why we ship with a particular version of the CMF), and we have never
supported newer/older CMF releases in any version of Plone. This has
practical consequences in making it one less deprecation chain cascading
to pay attention to.
So if the breakage (haven't followed the thread in detail) only occurs if
you try using Plone 2.1 with CMF 1.6, that is indeed a non-issue. Plone
2.5 is the version that targets CMF 1.6.
--
_
Alexander Limi · Chief Architect · Plone Solutions · Norway
Consulting · Training · Development · http://www.plonesolutions.com
_
Plone Co-Founder · http://plone.org · Connecting Content
Plone Foundation · http://plone.org/foundation · Protecting Plone
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On Wed, 21 Dec 2005 13:29:09 +0100, Rocky Burt
<[EMAIL PROTECTED]> wrote:
Just a terminology correction here, the next version of Plone is 2.5,
not 2.2 - we changed our version policy a while back:
Well now I'm *completely* confused.
s/Plone 2.2/Plone 2.5/g
Better? ;)
--
_
Alexander Limi · Chief Architect · Plone Solutions · Norway
Consulting · Training · Development · http://www.plonesolutions.com
_
Plone Co-Founder · http://plone.org · Connecting Content
Plone Foundation · http://plone.org/foundation · Protecting Plone
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On Wed, 21 Dec 2005 00:32:02 +0100, yuppie
<[EMAIL PROTECTED]> wrote:
AFAICT the original target audience were people that want to switch to
Plone 2.2 and reuse Products written for 2.1.
Just a terminology correction here, the next version of Plone is 2.5, not
2.2 - we changed our version policy a while back:
http://plone.org/products/plone/roadmap/114
http://plone.org/roadmap
(Not that important for this discussion, but just a heads-up so you
non-Plone people don't get confused about 2.2 vs. 2.5 when we talk about
it later. :)
--
_
Alexander Limi · Chief Architect · Plone Solutions · Norway
Consulting · Training · Development · http://www.plonesolutions.com
_
Plone Co-Founder · http://plone.org · Connecting Content
Plone Foundation · http://plone.org/foundation · Protecting Plone
___
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: Re: Re: Re: VIRTUAL_URL and ACTUAL_URL (was Re: Collector Issues)
On Tue, 06 Dec 2005 22:03:46 -0800, Andreas Jung <[EMAIL PROTECTED]> wrote: That's what we do, but it defeats the purpose of the variable in the first place - which was to have an easy way for Zope templating people to create anchor tags that work. The primary reason to add ACTUAL_URL was to have a reliable variable for both vhost and non-vhost environment as far as I remember. You remember wrong. From the bug[1]: "The short summary is that there's no good way of getting the URL of the current page (ie. what it actually says in the URL field) as opposed to what Zope reports as the object URL." VIRTUAL_URL will give you what you are describing above (since its inclusion by default in Zope). This is *not* the use case for ACTUAL_URL. I can't remember why the implementation ended up without the query string Because the person implementing it (and the ones that tested it, including me) didn't notice that it didn't contain the query string. Hence, it is a bug. but as you said you can easily deal with this issue by using a global define. Look, I'm just trying to make Zope a bit more friendly to new developers. Of course, this seems to not be a priority. I'll stop bitching, but the next time people complain about Plone "putting things in the wrong layer of the stack", I'll point them to this. If being able to use an anchor tag from ZPT without implementing your own variable isn't base-level functionality, I don't know what is. [1] http://www.zope.org/Collectors/Zope/1568 and http://www.zope.org/Collectors/Zope/1252 -- _____ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ 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: Re: Re: VIRTUAL_URL and ACTUAL_URL (was Re: Collector Issues)
On Sun, 04 Dec 2005 22:38:08 -0800, Andreas Jung
<[EMAIL PROTECTED]> wrote:
Thus, a link like will *reload the page*, then
go to the anchor - which is clearly not desirable behaviour.
Why can't you define your own concatenation of ACTUAL_URL + query string
within the global definitions of Plone?
That's what we do, but it defeats the purpose of the variable in the first
place - which was to have an easy way for Zope templating people to create
anchor tags that work.
--
_
Alexander Limi · Chief Architect · Plone Solutions · Norway
Consulting · Training · Development · http://www.plonesolutions.com
_
Plone Co-Founder · http://plone.org · Connecting Content
Plone Foundation · http://plone.org/foundation · Protecting Plone
___
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: VIRTUAL_URL and ACTUAL_URL (was Re: Collector Issues)
On Sun, 04 Dec 2005 07:24:36 -0800, yuppie <[EMAIL PROTECTED]> wrote: Intended or not, ACTUAL_URL was released with a specific behavior that is useful for and used by some people. You can't change the behavior of ACTUAL_URL in a non backwards compatible way just to make it more suitable for your use cases. The original use case for ACTUAL_URL was to use with anchors, and that's why it is a bug, not intentional behaviour. If you want a variable *without* the query string (which is by far a much less common use case) that's fine - but *that* should be the new variable, not the old one. It was even added in a point release, so the "changing the behaviour" isn't really a good argument. The implementation was not complete in the first version - and I filed a bug report on it. -- _____ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ 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: Re: VIRTUAL_URL and ACTUAL_URL (was Re: Collector Issues)
On Sun, 04 Dec 2005 10:23:25 -0800, Dieter Maurer <[EMAIL PROTECTED]> wrote: 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. 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 value to something else than the current page. Thus, a link like will *reload the page*, then go to the anchor - which is clearly not desirable behaviour. -- _____ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ 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: VIRTUAL_URL and ACTUAL_URL (was Re: Collector Issues)
On Sat, 03 Dec 2005 10:04:52 -0800, Andreas Jung <[EMAIL PROTECTED]> wrote: AFAIK ACTUAL_URL contains the full URL *plus* the query string. VIRTUAL_URL does not contain the query string. ACTUAL_URL was introduced on request by the Plone developers. 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?). When I suggested that it should be fixed, people wanted to invent *another* variable that included the query string, and it degenerated into a "what should we name it" discussion after that. So that thing still has to be "reinvented" in Plone, which sucks. -- _____ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ 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: upgrade question
Please forward this to the Plone Setup list, which deals with installation
and migration of Plone. The CMF team does not have the capacity to field
Plone questions, nor should they have to. ;)
http://plone.org/contact#setup
-- Alexander Limi
On Fri, 18 Nov 2005 14:08:55 -0800, Steve Giessler
<[EMAIL PROTECTED]> wrote:
Greetings,
I'm upgrading Zope 2.7.6 (with Python 2.3.5) and Plone 2.0.5 to Zope
2.8.4 (with Python 2.3.5) and Plone 2.1.1 (and PIL 1.1.5). This is all
being done on a RHEL 4 box. I installed all the new stuff and then I
copied my Data.fs file to the new instance/var directory. I then ran the
new Plone instance, went to mysite:8080/manage and in the ZMI migrated
my plone sites. During migration, each site gave me many pages of these
errors:
snippet
2005-11-18 12:46:04 INFO Zope.ZCatalog Finished migration of indexes for
clc/portal_catalog
2005-11-18 12:46:08 ERROR ExtendedPathIndex Attempt to unindex
nonexistent document with id -1984665228
2005-11-18 12:46:16 ERROR ExtendedPathIndex Attempt to unindex
nonexistent document with id -1984665227
2005-11-18 12:46:26 ERROR ExtendedPathIndex Attempt to unindex
nonexistent document with id -1984665226
2005-11-18 12:46:32 ERROR ExtendedPathIndex Attempt to unindex
nonexistent document with id -1984665225
2005-11-18 12:46:35 ERROR ExtendedPathIndex Attempt to unindex
nonexistent document with id -1984665224
2005-11-18 12:46:36 ERROR ExtendedPathIndex Attempt to unindex
nonexistent document with id -1984665223
2005-11-18 12:46:38 ERROR ExtendedPathIndex Attempt to unindex
nonexistent document with id -1984665222
snippet
but the sites still seem to run (the basic framework and skins, etc are
visible). When I hit my plone site though, I see this on the main page:
This site encountered an error trying to fulfill your request. The
errors were:
Error Type
RuntimeError
Error Value
maximum recursion depth exceeded
Request made at
2005/11/18 17:02:17.389 US/Eastern
And in the Zope log output I see:
2005-11-18 17:01:34 INFO Zope Ready to handle requests
/zope/main_instance/Products/CMFCore/TypesTool.py:275:
DeprecationWarning: getActionById() is deprecated and will be removed in
CMF 1.6. Please use getActionInfo()['url'] if you need an URL or
queryMethodID() if you need a method ID.
DeprecationWarning)
/zope/main_instance/Products/CMFCore/utils.py:186: DeprecationWarning:
__call__() and view() methods using _getViewFor() as well as
_getViewFor() itself are deprecated and will be removed in CMF 1.6.
Bypass these methods by defining '(Default)' and 'view' Method Aliases.
DeprecationWarning)
2005-11-18 17:02:16 ERROR Zope.SiteErrorLog
http://www.as.wvu.edu:8080/clc/index_html
Traceback (most recent call last):
File "/zope/lib/python/ZPublisher/Publish.py", line 113, in publish
request, bind=1)
File "/zope/lib/python/ZPublisher/mapply.py", line 88, in mapply
if debug is not None: return debug(object,args,context)
File "/zope/lib/python/ZPublisher/Publish.py", line 40, in call_object
result=apply(object,args) # Type s to step into published object.
File "/zope/main_instance/Products/CMFCore/PortalContent.py", line
109, in __call__
return method()
File "/zope/main_instance/Products/CMFCore/PortalContent.py", line
109, in __call__
return method()
File "/zope/main_instance/Products/CMFCore/PortalContent.py", line
109, in __call__
return method()
File "/zope/main_instance/Products/CMFCore/PortalContent.py", line
109, in __call__
return method()
File "/zope/main_instance/Products/CMFCore/PortalContent.py", line
109, in __call__
return method()
File "/zope/main_instance/Products/CMFCore/PortalContent.py", line
109, in __call__
return method()
File "/zope/main_instance/Products/CMFCore/PortalContent.py", line
109, in __call__
return method()
File "/zope/main_instance/Products/CMFCore/PortalContent.py", line
109, in __call__
return method()
--snip (excess removed)---
File "/zope/main_instance/Products/CMFCore/PortalContent.py", line
100, in __call__
method_id = ti and ti.queryMethodID('(Default)', context=self)
File "/zope/main_instance/Products/CMFDynamicViewFTI/fti.py", line
221, in queryMethodID
methodTarget = self.defaultView(context)
File "/zope/main_instance/Products/CMFDynamicViewFTI/fti.py", line
189, in defaultView
obj, path = plone_utils.browserDefault(context)
File "/zope/main_instance/Products/CMFPlone/PloneTool.py", line 1095,
in browserDefault
act = obj.getTypeInfo().getActionById('view')
File "/zope/main_instance/Products/CMFCore/TypesTool.py", line 282, in
getActionById
target = action.action(context).strip()
F
[Zope-CMF] Re: CMF 1.6
On Fri, 18 Nov 2005 05:49:46 -0800, Chris Withers
<[EMAIL PROTECTED]> wrote:
Rant accepted, and understood. Still, you could try to help out instead of
*just* bitching. I am an expert bitcher myself, but at least I do
something about it. Thread closed? Feel free to follow up with me in
private email if there's anything we can do to facilitate you helping out.
--
_
Alexander Limi · Chief Architect · Plone Solutions · Norway
Consulting · Training · Development · http://www.plonesolutions.com
_
Plone Co-Founder · http://plone.org · Connecting Content
Plone Foundation · http://plone.org/foundation · Protecting Plone
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6
On Fri, 18 Nov 2005 00:37:47 -0800, Chris Withers
<[EMAIL PROTECTED]> wrote:
Alec Mitchell wrote:
to start using it immediately or risk strange breakages. Maintaining
product compatibility between versions of CMF/Plone will become nearly
impossible.
I'm sorry, I really couldn't resist this...
And that differs from other Plone releases how exactly? ;-)
And what, exactly, have you done to help Plone have less bugs? I know you
get income from Plone consulting, how about making your workday better
*and* pay back for the stuff you get for free?
You are seriously starting to piss me off, Chris - as the only person in
the Zope world so far. An achievement in itself, but not one you should be
particularly proud of.
--
_
Alexander Limi · Chief Architect · Plone Solutions · Norway
Consulting · Training · Development · http://www.plonesolutions.com
_
Plone Co-Founder · http://plone.org · Connecting Content
Plone Foundation · http://plone.org/foundation · Protecting Plone
___
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: Finding the current skin name
Can anybody from the CMF team give some guidance to Laurence here?
-- Alexander
On Fri, 28 Oct 2005 06:31:42 -0700, Laurence Rowe <[EMAIL PROTECTED]> wrote:
In Plone ResourceRegistries (1.1 branch) I need to get the current skin
name so that the resource (a css or js file) is fetched from the correct
skin. Unfortunately it seems that there is no easy way to get the
current skin name (when it is not set by a cookie in the request). I can
work around this like follows, but it's a bit ugly:
security.declareProtected(permissions.View, 'getCurrentSkinName')
def getCurrentSkinName(self):
"""Returns the id of the current skin.
Ugh, there really should be a better way of doing this. This is
depending on internals in CMFCore and should be added there.
"""
skintool = getToolByName(self, 'portal_skins')
default_skin_name = skintool.getDefaultSkin()
tid = get_ident()
if SKINDATA.has_key(tid):
skinobj, ignore, resolve = SKINDATA.get(tid)
current_skin_path = skinobj.getPhysicalPath()
#
# Perhaps test against default skin first?
#
skinnames = skintool.getSkinSelections()
# loop through skin names looking for a match
for name in skinnames:
skin = skintool.getSkinByName(name)
path = skin.getPhysicalPath()
if current_skin_path == path:
return name
return default_skin_name
Would it be reasonable to make
Skinnable.SkinnableObjectManager.changeSkin set the skin request var
name after changing the skin? Such as:
security.declarePublic('changeSkin')
def changeSkin(self, skinname):
'''Change the current skin.
Can be called manually, allowing the user to change
skins in the middle of a request.
'''
skinobj = self.getSkin(skinname)
if skinobj is not None:
tid = get_ident()
SKINDATA[tid] = (skinobj, {}, {})
REQUEST = getattr(self, 'REQUEST', None)
if REQUEST is not None:
REQUEST._hold(SkinDataCleanup(tid))
sfn = self.getSkinsFolderName()
if sfn is not None:
sf = getattr(self, sfn, None)
if sf is not None:
REQUEST.set(sf.getRequestVarname(), skinname)
Then getSkinNameFromRequest would work happily. Or is the a better way
to do this?
Regards,
Laurence
___
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
--
_
Alexander Limi · Chief Architect · Plone Solutions · Norway
Consulting · Training · Development · http://www.plonesolutions.com
_
Plone Co-Founder · http://plone.org · Connecting Content
Plone Foundation · http://plone.org/foundation · Protecting Plone
___
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: Re: Re: CachingPolicyManager improvements
On Tue, 06 Sep 2005 06:18:30 +0200, Geoff Davis <[EMAIL PROTECTED]> wrote: RAMCacheManager has no good way to purge stale content. RAMCacheManager is limited to RAM for its cache. Etc. And the biggest etc: RAMCache does not know how to handle anything but 7-bit ASCII data. -- _ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ 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: Re: CachingPolicyManager improvements
On Mon, 05 Sep 2005 22:20:02 +0200, Geoff Davis <[EMAIL PROTECTED]> wrote: Alternatively you can create a function that checks the modification times for the content and for all portlets as well. Embed that composite time in your ETag and you're all set. ESI would be cool, too, but I'm not betting that we'll see that any time soon. The new PlonePortlets infrastructure could help here too, the plan is to have built-in caching parameters for each portlet here - so it can know whether it has fresh content or not, and feed that to external mechanisms like the ETags. Still science fiction, though. ;) (And before you ask - yes, we're putting it in the Collective shortly. :) -- _____ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ 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: CachingPolicyManager improvements
On Sat, 03 Sep 2005 22:16:14 +0200, Jens Vagelpohl <[EMAIL PROTECTED]> wrote: Part of Zope version 2.8 and up, that's the problem. If you were to run a clean Zope 2.7.x, downloaded a release version of CMF 1.5.x and ran the unit tests, would you expect to see any breakage? I wouldn't want to see that at all if I were a normal user. Of course I *absolutely hate* to see that as a CMF developer in the same situation ;) I think you have an interesting definition of "normal user". :] Normal users won't run unit tests until we give them a big shiny button to click, and a nice green progress bar to watch. We're working on it, though. ;) -- _____ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ 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
