Am 26.06.2007 um 08:42 schrieb yuppie:
Please don't do that. For the tools in the list quoted above
getToolByName is your best choice, at least for now.
I just removed the misleading deprecation warning from the trunk.
(This was already done on the 2.1 branch, but never forward ported.)
Hi!
Hanno Schlichting wrote:
yuppie wrote:
Wichert Akkerman wrote:
Previously yuppie wrote:
MembershipTool depends on acl_users
MemberDataTool, RegistrationTool, DiscussionTool and
CachingPolicyManager depend on MembershipTool
From what I can see in the Plone tests it won't be possible in
Previously yuppie wrote:
> Charlie Clark wrote:
> >
> >Am 23.06.2007 um 14:53 schrieb yuppie:
> >
> >>There are 10 tools in CMF that are not ready for being used as
> >>utilities, they have to be used the old way until they are fixed:
> >>
> >>content_type_registry
> >>cookie_authentication
> >>po
Charlie Clark wrote:
Am 23.06.2007 um 14:53 schrieb yuppie:
There are 10 tools in CMF that are not ready for being used as
utilities, they have to be used the old way until they are fixed:
content_type_registry
cookie_authentication
portal_actions
portal_calendar
portal_catalog
portal_skins
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
Am 23.06.2007 um 14:53 schrieb 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.
Done:
-
There are 10 to
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 co
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. In there it is availab
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
Wichert Akkerman wrote:
Previously yuppie wrote:
Wichert Akkerman wrote:
Previously yuppie wrote:
- figure out if we can make acl_users an utility
User folders, or their plugins, seem to have a tendency to rely on
self.REQUEST so that is probably not going to work.
:(
MembershipTool depend
Previously yuppie wrote:
> Wichert Akkerman wrote:
> >Previously yuppie wrote:
> >>- figure out if we can make acl_users an utility
> >
> >User folders, or their plugins, seem to have a tendency to rely on
> >self.REQUEST so that is probably not going to work.
>
> :(
>
> MembershipTool depends o
Wichert Akkerman wrote:
Previously yuppie wrote:
- figure out if we can make acl_users an utility
User folders, or their plugins, seem to have a tendency to rely on
self.REQUEST so that is probably not going to work.
:(
MembershipTool depends on acl_users
MemberDataTool, RegistrationTool,
Previously yuppie wrote:
> - figure out if we can make acl_users an utility
User folders, or their plugins, seem to have a tendency to rely on
self.REQUEST so that is probably not going to work.
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things.
http://www.wiggy.n
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
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
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! :)
Done:
-
There are 10 tools in
yuppie wrote:
Hi!
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.
Thanks !
AFAICS, KSS will no longer need the monkey
Hi!
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.
Done:
-
There are 10 tools in CMF that are not ready for being u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18 Jun 2007, at 11:30, Hanno Schlichting wrote:
Does that make sense? If there are no objections I'll move on in that
direction. This week I have some time to work on the implementation.
+1 from me.
I think we are at a point where any solutio
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
20 matches
Mail list logo
