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 Z
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 (Messag
Lennart Regebro wrote:
> On 2/23/06, yuppie <[EMAIL PROTECTED]> wrote:
>> Currently the portal status message is always translated in the i18n
>> domain of main_template if sent through a redirect. This makes it
>> impossible to use different domains (and mappings or defaults).
>>
>> Add-on product
Hi Jens, all!
For the uninitiated I'm the poor guy that signed up to work on getting
Plone trunk (aka 3.0) to work with current CMF trunk (aka 2.1) amongst
other things ;)
According to the roadmap for the next Plone release we currently aim for
Plone 3.0-final to be released in January 2007. More
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
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.
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 GSLocalAd
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
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 merg
Jens Vagelpohl wrote:
>
> On 6 Jan 2007, at 15:34, Hanno Schlichting wrote:
>> I had to change two things in CMF so far though. Here are the patches I
>> came up with:
>
> Thanks Hanno, this is a point I wanted to bring up after getting the
> last work done: When using
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 u
Tres Seaver wrote:
> Rocky Burt wrote:
>> On Sat, 2007-06-01 at 16:32 +0100, Hanno Schlichting wrote:
>>> Hhm, I'm not sure what the best way is here. Personally I would like to
>>> get rid of as much of Acquisition as possible, but obviously we need to
Martin Aspeli wrote:
> Hanno Schlichting wrote:
>
>> Yep, you are wrong ;)
>
> Fair enough. Out of curiosity, does the object have a __parent__?
Nope, not ILocation aware :(
> In any case, I think your original suggestion is a good one. Let's take
> this opportunit
Martin Aspeli wrote:
> Hanno Schlichting wrote:
>
>> PhiliKON some time ago suggested that Five should wrap the utilities
>> eventually but nobody followed up on that idea.
>
> Philipp also has some ideas (not too far off completion, I believe) that
> may rem
Jens Vagelpohl wrote:
>
> Now, the main issue is still there, how to deal with tool wrapping when
> calling getUtility/queryUtility in trusted code. Doing it every time
> right after the call is stupid. I like Tres' hardline assertion that we
> must have it wrapped every time, automatically. This
Philipp von Weitershausen wrote:
> On 6 Jan 2007, at 23:22 , Martin Aspeli wrote:
>
> Actually, why dont you keep a simple mapping between existing names and
> interfaces, e.g.:
>
> name2iface = {'portal_catalog': ICatalog,
> 'portal_skins': ISkinTool,
> ...}
>
> and u
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
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
a
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
>> no
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
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
Tres Seaver wrote:
> Martin Aspeli wrote:
>> Jens Vagelpohl wrote:
>
>>> All those who think this is somehow impure and dirty, keep in mind
>>> that this arrangement won't be forever, only for the 2.1 branch.
>>> Afterwards there's more time to plan on packaging things differently.
>> The only
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 proble
Hi,
yuppie wrote:
> Apparently I'm missing something because this doesn't make much sense to
> me:
>
> ComponentRegistryXMLAdapterTests use
> z.c.persistentregistry.PersistentComponents. These tests register
> wrapped tools, the registry returns them with their original wrapper.
>
> If I add tra
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,
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 separa
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 __before_publishing_tra
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
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 hav
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:
>
>
>
>> 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 ma
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 Attribut
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
>
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
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
>
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
S
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
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) th
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
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
>>> configurat
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
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
>
> Not
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 Launchp
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 el
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 th
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 re
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
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 pag
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 a
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 http://collector.zo
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
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 separa
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
decode
For those of you not reading the launchpad-users mailing list, there has
been an update which introduces a new option:
* You now have the option of receiving the full original bug report in
all bug notification emails. Visit https://launchpad.net/name>/+edit then check the "Include bug descript
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 whatsoev
yuppie wrote:
Wichert Akkerman wrote:
Previously yuppie wrote:
Until recently, the Products themselves didn't use setuptools.
Revision 85287 (http://svn.zope.org/?rev=85287&view=rev) changed
that. It is no longer possible to run CMF without setuptools installed.
For those of you who didn't r
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 de
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 picke
Hi.
Dieter Maurer wrote:
I tried to easy_install CMFCore from PyPI -- this failed.
Not supported yet :)
Apparently, "CMFCore" is only registered on "PyPI", not uploaded (this
is okay).
I registered all the package names a while back, but forgot to remove
the 2.2.dev releases again. This i
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 in
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
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
>>
yuppie wrote:
> CMFDefault registers portal_setup as utility. Some code in CMF depends
> on that.
>
> Plone doesn't doesn't register portal_setup as utility:
> http://dev.plone.org/plone/changeset/18763
>
> That causes some trouble in Plone:
> http://dev.plone.org/plone/ticket/7714
>
> The same
Hi.
yuppie wrote:
> I just noticed this checkin: http://svn.zope.org/?rev=94014&view=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 fin
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
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
>>Configur
yuppie wrote:
> Hanno Schlichting wrote:
>> In a package based world, if you specify a dependency on a package, you
>> can in my opinion only rely on the package contents itself to be there.
>> You cannot rely on its dependencies to stay around.
>
> I agree with you
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 p
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
http://www.zope.org
yuppie wrote:
> 2.) get rid of redundant type info properties
> -
>
> See http://mail.zope.org/pipermail/zope-cmf/2009-January/028059.html
>
> Unfortunately nobody seems to feel responsible for this.
My mail had: "I have one small todo item on my list
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'
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.
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 unrelea
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
>
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
On Mon, Aug 3, 2009 at 10:46 PM, toutpt 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 done over
the las
On Mon, Aug 3, 2009 at 11:09 PM, toutpt 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 no longer su
On Fri, Aug 7, 2009 at 9:17 PM, toutpt wrote:
> experimental.opaquespeedup is good but not enough for me. The load tests
> results are not enough, I want to be more 'aggressive' and
> experimental. For me this package is backward compatible and do a
> catalog query instead of parsing all attribute
On Sat, Aug 8, 2009 at 12:14 AM, Charlie Clark 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 before you write a
On Mon, Aug 17, 2009 at 5:48 PM, Alec Mitchell 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 change looks pe
80 matches
Mail list logo
