[Zope-CMF] cmf-tests - OK: 4
This is the summary for test reports received on the cmf-tests list between 2011-09-28 00:00:00 UTC and 2011-09-29 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received CMF-2.2 Zope-2.12 Python-2.6.6 : Linux CMF-2.2 Zope-2.13 Python-2.6.6 : Linux CMF-trunk Zope-2.13 Python-2.6.6 : Linux CMF-trunk Zope-trunk Python-2.6.6 : Linux Non-OK results -- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] working on the trunk
Am 29.09.2011, 14:14 Uhr, schrieb yuppie :
> Yes.
I've hit a bit of a problem with folder syndication - I already have an
annotations adapter for storing the values on the folder and I can extend
this to be able to handle individual values rather than a dictionary but
ProxyFieldProperties don't work because the adapter itself doesn't support
properties. I also have some additional methods on the adapter that I use
from the view. What do you think is the best way to proceed here? Subclass
the SchemaAdapter so that the encoding and DateTime stuff works okay? For
the methods I don't see any alternative but to expose the annotations
adapter explicitly within the view. Bit of a muddle, I guess.
>> I still need to set view.adapters = {} for some reason but that's okay.
> zope.formlib expects that setUpWidgets is always called before
> handle_change. If you test handle_change isolated, you have to set
> adapters by hand.
My tests never call setUpWidgets - that is almost impossible from within
unittests. But applyChanges expects an adapters dictionary for the form
even it's empty.
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] working on the trunk
Charlie Clark wrote:
> SettingsEditFormBase landed after my sturm and drang work last year. So
> you generally replace my explicit calls to tools with getContent? I guess
> I just need some proxyFields for enabling and disabling.
Yes.
> I still need to set view.adapters = {} for some reason but that's okay.
zope.formlib expects that setUpWidgets is always called before
handle_change. If you test handle_change isolated, you have to set
adapters by hand.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] working on the trunk
Hi Yuppie,
thanks as ever for the helpful explanation.
Am 29.09.2011, 10:39 Uhr, schrieb yuppie :
> SettingsEditFormBase has a getContent() method similar to that in
> z3c.form. This allows a clean distinction between 'content' and
> 'context'. For content objects they are usually the same, but in your
> case the site root is the context and the (adapted) SyndicationTool is
> the edited "content".
SettingsEditFormBase landed after my sturm and drang work last year. So
you generally replace my explicit calls to tools with getContent? I guess
I just need some proxyFields for enabling and disabling. Had to throw in
some additional adapters to make the tests happy but test_handle_change
now works as it should. I guess unittesting views is pushing things a bit
but I like it if I can get it to work.
> Please have a look at the membership views. They show how to use
> getContent(). In your case the method would look like this:
> @memoize
> def getContent(self):
> syndtool = getUtility(ISyndicationTool)
> return SyndicationToolSchemaAdapter(syndtool)
> This example uses a hardcoded adapter. You can still register it and
> look it up, but I guess that's overkill.
Indeed.
> I doubt anybody wants to use a customized adapter. And if it is
> hardcoded, you don't need to register
> it for testing.
I still need to set view.adapters = {} for some reason but that's okay.
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] working on the trunk
Hi Charlie! Charlie Clark wrote: > Am 27.01.2011, 17:05 Uhr, schrieb yuppie: > >> zope.formlib is not made for DateTime values and encoded strings. So you >> *always* have to make sure these values are converted correctly. And it >> is hard to do that inside the form code. Obviously you did have trouble >> to get it right that way. After I started using adapters for the edited >> objects I had much less trouble using formlib. Of course you don't need >> an adapter if your objects already provide the right interface. > >> And one more benefit: Inside the form code you can completely ignore the >> old-fashioned implementation of the edited objects and write nice modern >> code. > > Finally have made the time to look at this. I've written a schema adapter > for the forms and it looks like SettingsEditForm handles the conversion to > Zope's DateTime nicely. Now, I'm stuck with the problem of getting my view > unit tests to work. Looks like I need a few adapters registered. :-/ SettingsEditFormBase has a getContent() method similar to that in z3c.form. This allows a clean distinction between 'content' and 'context'. For content objects they are usually the same, but in your case the site root is the context and the (adapted) SyndicationTool is the edited "content". Please have a look at the membership views. They show how to use getContent(). In your case the method would look like this: @memoize def getContent(self): syndtool = getUtility(ISyndicationTool) return SyndicationToolSchemaAdapter(syndtool) This example uses a hardcoded adapter. You can still register it and look it up, but I guess that's overkill. I doubt anybody wants to use a customized adapter. And if it is hardcoded, you don't need to register it for testing ;) Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Switching to Chameleon
Hi Laurence! Laurence Rowe wrote: > Plone tends to wait for CMF to stabilise before thinking of moving to > a new version. I doubt that strategy will work for Plone: Most CMF installations are part of Plone installations. And Plone uses CMF in different ways than other CMF installations. So the best way to get a battle-tested CMF release is to help testing. Besides that: Did you ever see trouble with unstable CMF releases? > At least when I last looked around a year ago (after > adding some workflow pluggability into CMF) CMF trunk broke far too > much in Plone to consider it for a minor revision. Was the Plone version you used for testing Zope 2.13 compatible? At that time CMF trunk didn't have many changes that affect Plone. The tools-as-utilities changes I recently made might require more work on the Plone side. Especially in test setups. > Hopefully someone > will put the effort in to port Plone to CMF 2.3 in time for Plone 5. Who ever that is: The upgrade steps for CMFDefault might give some hints what needs to be upgraded. And you are always welcome to ask questions on this list if you have trouble with upgrading. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
