On Mon, Aug 17, 2009 at 5:48 PM, Alec Mitchellap...@columbia.edu wrote:
It may make the
most sense to remove the Quoted Printable config from MailHost and
just punt this decision to some future release.
Currently your changes only apply to Zope trunk aka 2.13 which is in
early development. The
On Sat, Aug 8, 2009 at 12:14 AM, Charlie Clarkchar...@begeistert.org wrote:
Is the patch for Plone or CMF?
It's for Plone, I guess. The problem is solved in Plone 4.0 itself
(via monkey-patching CMF).
If it's for CMF then you should consider simply submitting a patch or
opening a branch. But
On Mon, Aug 3, 2009 at 10:46 PM, toutpttou...@gmail.com wrote:
I m currently profiling the code of Plone to find performance issue and
fix them (i m sure there are a lot).
Did you try to install all the experimental.* (opaquespeedup,
contentcreation, catalogqueryplan) packages that have been
On Mon, Aug 3, 2009 at 11:09 PM, toutpttou...@gmail.com wrote:
I don't really understand why all these improvements are not merged
inside plone3.X and CMF and are marked up as 'experimental'.
The opaque items issue at hand is not a simple and clear bug fix. On
the Plone level we have decided to
Jens Vagelpohl wrote:
On May 26, 2009, at 10:21 , Wichert Akkerman wrote:
Previously Jens Vagelpohl wrote:
The CMF eggs, even on trunk, still advertise compatibility with Zope
2.10. I believe we had agreed to target Zope 2.12 with trunk - please
correct me if that's wrong. If we do want Zope
Wichert Akkerman wrote:
Previously yuppie wrote:
I'd like to change install_requires to 'zope.component 3.6dev' and
make tests work with zope.component 3.5.1 and older versions.
Any objections?
I'd just remove the version number altogether. If this version works
with a yet unreleased
yuppie wrote:
I doubt you can satisfy the requirements for five.localsitemanager 2.0
in a Zope version older than 2.12. That's why Zope2 = 2.12.dev is
specified as dependency. I thought you were fine with that.
five.localsitemanager 1.x doesn't depend on eggified Zope versions, so
we
Martin Aspeli wrote:
Jens Vagelpohl wrote:
Is there any kind of low-traffic announcement list for things like
PLIPs? I'm not subscribed to any Plone list because of (for me at
least) signal to noise ratio fears.
There's plone-announce, but I don't think this was announced there.
yuppie wrote:
That would mean that CMFDefault-the-example-application will depend on
z3c.form. If we are going to split off the forms we need to split off
all browser views and the profiles that use these views. Something like
'cmf.app' that includes all the CMFDefault stuff Plone doesn't
Hi.
Quoting a mail from Jens from September last year:
Is there anything to hold back a CMF 2.2.0 beta at this point?
I have one small todo item on my list regarding the changes to content
type icons.
Things I remember people working on:
- Formlib based views
- Add-views
Hanno Schlichting wrote:
If a package only depends on Acquisition, DateTime and zope.* packages
it does no longer depend on Zope2. I'd like to encourage people to
look at their real dependency and be honest about those. Especially
looking at things from the perspective of: why does my package
Charlie Clark wrote:
Am 03.02.2009 um 13:45 schrieb Hanno Schlichting:
ZopeXMLConfigurationError: File
/home/stefan/autotest/temp/python24-zope212-cmf22/Products/
CMFDefault/skin/configure.zcml,
line 12.2
ConfigurationError: ('Unknown directive',
u'http://namespaces.zope.org/browser
CMF Tests Summarizer wrote:
Summary of messages to the cmf-tests list.
Period Mon Feb 2 12:00:00 2009 UTC to Tue Feb 3 12:00:00 2009 UTC.
There were 6 messages: 6 from CMF Tests.
Test failures
-
Subject: FAILED (failures=2, errors=3) : CMF-trunk Zope-trunk Python-2.5.4 :
Hi.
yuppie wrote:
I just noticed this checkin: http://svn.zope.org/?rev=94014view=rev
And I'm a bit confused. What's the plan? Maintaining redundant
information? Using a different icon for the add action? Deprecating
content_icon and migrating everything to icon_expr?
I would be fine
Jens Vagelpohl wrote:
On Oct 4, 2008, at 17:28 , Hanno Schlichting wrote:
Jens Vagelpohl wrote:
Is anyone actually using the portal_fiveactions tool and the supposed
bridging between Z3 menus and CMF actions it is promising? I'm
wondering if it's dead wood we're carrying around since
Jens Vagelpohl wrote:
Is anyone actually using the portal_fiveactions tool and the supposed
bridging between Z3 menus and CMF actions it is promising? I'm
wondering if it's dead wood we're carrying around since it really has
not been touched much after the initial import:
I think nobody is
Hi.
There's two issues here. One is with quick installer and one is with
GenericSetup. This mailing list is not the right place to discuss issues
with the first, please do that on the Plone developers mailing list.
Nathan Van Gheem wrote:
Martin Aspeli pointed out,
I think the problem is
Hi.
Maurits van Rees wrote:
This is on Plone 3.0 with CMFQuickInstaller 2.0.4.
I think you are on the wrong list here. QuickInstaller is a part of
Plone and not CMF and should be discussed on plone-dev. I'll give some
responses anyways ;)
Question 1: can I influence which profile is
Hi.
CMF Tests Summarizer wrote:
Unknown
---
Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.4.4 : Linux
From: CMF Tests
Date: Sat Apr 26 21:58:24 EDT 2008
URL: http://mail.zope.org/pipermail/cmf-tests/2008-April/008623.html
I fixed the test failure, which was introduced by me removing
yuppie wrote:
Wichert Akkerman wrote:
Previously yuppie wrote:
Until recently, the Products themselves didn't use setuptools.
Revision 85287 (http://svn.zope.org/?rev=85287view=rev) changed
that. It is no longer possible to run CMF without setuptools installed.
For those of you who didn't
Jens Vagelpohl wrote:
There's an egg with version 0.3 on the cheeseshop, is that an acceptable
version? I simply linked in what I had here from the current CMFCore
trunk, but that external is against the five.localsitemanager trunk and
the package itself contains no version information
Charlie Clark wrote:
If I have non-ASCII data in an RDBMS that I wish to use in a CMF site or
even straight ZPT's you get a UnicodeError when accessing the non-ASCII
Values which you get around using the decode utility.
ZPT uses Unicode internally in Zope 2.10 and newer, so you need to
Tres Seaver wrote:
Jens Vagelpohl wrote:
On Dec 29, 2007, at 18:28 , Hanno Schlichting wrote:
For the small number of CMF parts I'm +1 for individual eggs.
I understood both comments as positive votes and have done the dirty
work of moving CMF trunk into separate parts now. I haven't moved
Jens Vagelpohl wrote:
By the way, I have attempted to upload the new GS 1.3.3 to the cheese
shop, but even though I have a login it told me I am not allowed to do
so. This is the first time I am uploading anything, and looking through
the scant documentation linked from the scheese shop pages
Jens Vagelpohl wrote:
On Dec 29, 2007, at 14:05 , Hanno Schlichting wrote:
The maintainer role can only manage releases and files, while the Owner
can add new users or delete the whole package from the cheese shop.
For GenericSetup Tres should probably add at least you as a second
Owner. He
Tres Seaver wrote:
I've now added Jens as 'Owner' on GS, PAS, and PR.
I added Jens and Tres as Owners to five.lsm as well.
Hanno
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See
Jens Vagelpohl wrote:
By the way, since Products.CMFCore already appears ready to be published
as an egg, is there anything missing before putting it into the index?
Not that I know of.
What's the status of moving all the other parts into separate projects /
folders?
FWIW there hasn't been a
Jens Vagelpohl wrote:
The CMF 2.1 branch has seen enough fixes since CMF 2.1.0 to make a
meaningful bugfix release. If there are no objections I would cut CMF
2.1.1-beta tomorrow (Friday 12/28) and a final a week later. I'm out of
town from tomorrow night until 1/1, that's why I would have to
yuppie wrote:
GenericSetup trunk has global step registries. I propose to use the new
ZCML directive for registering all GenericSetup and CMF import and
export steps globally. And to remove the import_steps.xml and
export_steps.xml files from the profiles shipped with CMF.
This also
Andreas Jung wrote:
is there a buildout recipe that can unpack the CMF source archive properly?
The problem is basically that the top-level folder contains the products
as subdirectories. So the product dirs must be moved or linked.
Sidnei already mentioned my recipe, but as I never found the
Philipp von Weitershausen wrote:
yuppie wrote:
Wichert Akkerman wrote:
A related question is: how do we want to eggify CMF? It seems to make
sense to create one egg for the whole of CMF and a second egg for
GenericSetup.
Why not one egg for each CMF product? Can you please elaborate?
Jens Vagelpohl wrote:
Now that the Zope and Zope3 collectors have been migrated successfully
onto Launchpad, and there seems to be a good routine in place to
preserve history and ensure automatic redirects, I wanted to bring up
the question again. Should we move the CMF collector to Launchpad?
Tres Seaver wrote:
SVN Reorganiztion
-
I just worked a bit today on spliting CMF 2.1.0 (GenericSetup 1.3.2) out
into separately releasable egg-based distributions. For the initial
pass, see:
svn://svn.zope.org/repos/main/Products.GenericSetup/tags/1.3.2
Note that
Jens Vagelpohl wrote:
Andreas Jung is in the process of getting the regular Zope 2 issue
collector moved onto Launchpad. He said the Launchpad guys could move
other collectors like the CMF collector at the same time. The question
is, do we want this?
My vote is -0.5, mostly because I never
Martin Aspeli wrote:
Hi guys,
After a lot of is-this-a-bug type discussions with Rob and Wichert,
I've come to feel pretty strongly about the following:
When you load an extension profile for the first time in GS, it looks to
see if it has any import steps (in import_steps.xml) that are
yuppie wrote:
Jens Vagelpohl wrote:
On 20 Jul 2007, at 11:00, Wichert Akkerman wrote:
Previously Jens Vagelpohl wrote:
Next step: What needs fixing for the final?
There has been a surprising lack of response to this question. Since I
need a CMF 2.1-final for Plone in a few weeks that could
Tres Seaver wrote:
Martin Aspeli wrote:
Tres Seaver wrote:
'importVarious' is a brutal hack: better to focus efforts on making it
disappear. The entire point of the tool is to externalize configuration
as declarative data in the profile; accomodating imperative
configuration is not
Wichert Akkerman wrote:
Previously Jens Vagelpohl wrote:
Next step: What needs fixing for the final?
There has been a surprising lack of response to this question. Since I
need a CMF 2.1-final for Plone in a few weeks that could be very
positive news for me but I have a suspicion that some
Wichert Akkerman wrote:
Can someone close issues 489 and 473? Both of them are fixed now, but I
don't have permission to mark them as closed.
Done :)
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
Jens Vagelpohl wrote:
On 3 Jul 2007, at 10:10, Wichert Akkerman wrote:
Now that the utility vs tool work seems to be settling down and we are
running Plone without any monkeypatches I want to get Plone 3.0-rc1
out the door start of next week. For that to happen I am going to need
a new
yuppie wrote:
Hi Hanno!
Hanno Schlichting wrote:
Starting any Plone tests will give an AttributeError on self.adapters in
the subscribers method of zope.component.registry.
The registry is actually the one from five.lsm and is found via the
zope.app.component.hooks.SiteInfo container
Hi.
I meanwhile managed to fix the issue that prevented all tests from
running and now the Plone 3.0 bundles use the head revision of the CMF
2.1 branch and five.lsm trunk again.
I have started to fix all the problems that have shown up now. We have
some custom tools for which I needed to remove
Hanno Schlichting wrote:
ToDo:
-
- real world testing
My testing of Plone 3.0 after the merge so far results in all
integration tests failing with that stupid error inside the component
registry when it throws an AttributeError on 'adapters'. The error
happened a few times already
Hi.
Martin Aspeli wrote:
Hi Yuppie,
This proposal is now implemented on CMF and five.localsitemanager
trunk. Everything *seems* to work, but maybe I'm missing something.
This might be a good time to review and test the changes - any
feedback is welcome.
Well done - great work! :)
Godefroid Chapelle wrote:
yuppie wrote:
snip
AFAICS, KSS will no longer need the monkey patch if it sets the
LookupClass to FiveVerifyingAdapterLookup.
I tried to test your code this evening...
This implied starting to fix Archetypes and Plone to work with all the
changes made in
Hi,
for some reason this change broken unit tests in all of the Plone
packages, starting with Archetypes, ATContentTypes up to CMFPlone. It
cannot find various skin methods and templates anymore.
Do you have some idea what could cause this? I have seen you introduced
a new
Hi,
yuppie wrote:
Yesterday I tried to do my homework from the CMF-mini-sprint in Potsdam.
I reread the tools-as-utilities discussion and had again a closer look
at the code. In Potsdam we decided to wrap persistent utilities with a
complete acquisition context. But now I think this would be
yuppie wrote:
Hanno Schlichting wrote:
for some reason this change broken unit tests in all of the Plone
packages, starting with Archetypes, ATContentTypes up to CMFPlone. It
cannot find various skin methods and templates anymore.
Do you have some idea what could cause this? I have seen
Hi,
I'll just offer one alternative solution for disussion, which could
avoid reverting all the changes we made.
Kapil Thangavelu wrote:
We believe that these recent changes have introduced implicit magic into
a standard Zope3 api to fit Zope2 acquisition. There should be an
explicit separate
Hi,
yuppie wrote:
The tools-as-utilities changes seem to run fine, but so far there is no
easy way to manage the tool registrations in the local site manager.
The site manager has no UI for inspecting or manipulating registrations,
so I tried to use GenericSetup:
I think this is on the
Hi,
Jens Vagelpohl wrote:
My checkins today addressed at least the second change set you list by
making the site itself a utility and looking it up that way. The
additional wrapping is gone as well.
I tested the branch again against the current Plone trunk and found no
branch related
Rocky Burt wrote:
On Mon, 2007-08-01 at 15:40 +0100, Philipp von Weitershausen wrote:
Since Five is feature-frozen and new stuff should be added in Python
packages anyway, my suggestion is to put this thing into a
five.localsitemanager package which would then be used by CMF 2.1, Plone
3,
Jens Vagelpohl wrote:
On 7 Jan 2007, at 14:26, Martin Aspeli wrote:
I didn't realise we would fully deprecate getToolByName() quite yet,
though. I must admit I haven't been following your checkins, for lack
of time (and since you're surely more qualified than me in this work
in any case).
Hi Jens,
Jens Vagelpohl wrote:
- I'll be happy to mark those places in the code where I had to
manually wrap after a straight getUtility/queryUtility call so these
places stand out as a reminder to do something about it.
I haven't marked those places yet, but attached you can find a patch
Dieter Maurer wrote:
Martin Aspeli wrote at 2007-1-6 22:22 +:
- Registering the portal as a utility that can be obtained by
getUtility(IPortalRoot) is pretty good practice; in my estimation, that
should solve all the use cases for utilities where acquisition is used
now and
Martin Aspeli wrote:
Jens Vagelpohl wrote:
Let's talk about something fun instead, like that wrapping issue. I
personally can't see any problem with Hanno's suggestion for a
special component registry and automatically wrapping those tools
that are in the little registry. I'm just
Jens Vagelpohl wrote:
On 6 Jan 2007, at 12:57, Andreas Jung wrote:
On 5 Jan 2007, at 20:51, Andreas Jung wrote:
I finished my work (including some test).
Any objections merging the changes back to the trunk?
If the tests pass, no. At least from me ;)
I merged the changes... hopefully
Martin Aspeli wrote:
Jens Vagelpohl wrote:
My concern is just that we need a robust solution that doesn't put too
much onus on the end developer. If I have to do this it's pretty
horrendous:
mtool = getUtility(IMembershipTool)
mtool = mtool.__of__(context)
# now use mtool
Hi Jens, all!
I haven't seen any progress on the tools as local utilities story for
some time now. Is there anything specific I can help with?
Jens Vagelpohl wrote:
On 22 Nov 2006, at 12:15, Hanno Schlichting wrote:
At the time I wrote this it was kind of experimental and I didn't know
if I
Hi Jens, all.
Why did you pick exactly the two weeks where I'm on vacation without an
Internet connection to do this?
Anyways by reading through the mailing list it seems you have figured it
all out by now ;)
Jens Vagelpohl wrote:
I have to run off right now, but a quick look over
Hi.
Jens Vagelpohl wrote:
Just out of curiosity, which dependencies does Plone 3.0 have that
require Zope 2.10? Or was it some papal edict to use 2.10?
It was more of an edict, to catch up with the latest versions of our
underlying frameworks again.
The two things we are actually relying on
Hi.
Jens Vagelpohl wrote:
I was under the impression there were a few show-stoppers that needed
CMF 2.1 (and in some cases Five) support that weren't there yet, like
the customize a skin item. Are there any items you know are missing?
You seem to apply you have everything you need.
The
Hi yuppie.
As the creator of the mentioned statusmessages product and the current
Plone i18n team lead I'm most interested in a general or at least
extensible solution to this.
The number one reason for the whole approach of the statusmessages
product was, that I wanted to use MessageID's
Hi.
These test failures are due to Five 1.1 monkey patching. See
http://article.gmane.org/gmane.comp.web.zope.z3base.five/756 or
http://article.gmane.org/gmane.comp.web.zope.plone.devel/9501 for some
more details.
Basically Five monkey patches the GlobalTranslationService adding a
wrapped
64 matches
Mail list logo
