Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Zope: CMF

[dev] working on the trunk

 

 

Zope cmf RSS feed   Index | Next | Previous | View Threaded


y.2011 at wcm-solutions

Jan 26, 2011, 7:50 AM

Post #1 of 17 (2418 views)
Permalink
[dev] working on the trunk

Hi!


I'm not happy with the current state of CMF trunk. Especially the
syndication related changes cause trouble in different ways:

- SyndicationInformation was replaced by SyndicationInfo without
providing migration code. Local syndication settings get lost in
existing sites.

- In the ZMI the SyndicationTool no longer has a tab that allows to
inspect and modify tool settings. The form that replaces the ZMI tab is
broken: It uses datetime objects instead of DateTime objects and mixes
them with existing DateTime settings.

Last week I reviewed parts of the new code and fixed some small issues.
But the bigger issues still exist. Based on what I encountered I wrote
this small guide: http://svn.zope.org/*checkout*/CMF/trunk/CODINGSTYLE.txt

Please keep the the trunk stable and use your own branch for unfinished
changes.


Cheers,

Yuppie
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


charlie.clark at clark-consulting

Jan 27, 2011, 6:59 AM

Post #2 of 17 (2331 views)
Permalink
Re: [dev] working on the trunk [In reply to]

Am 26.01.2011, 16:50 Uhr, schrieb yuppie <y.2011 [at] wcm-solutions>:

> I'm not happy with the current state of CMF trunk. Especially the
> syndication related changes cause trouble in different ways:
> - SyndicationInformation was replaced by SyndicationInfo without
> providing migration code. Local syndication settings get lost in
> existing sites.
> - In the ZMI the SyndicationTool no longer has a tab that allows to
> inspect and modify tool settings. The form that replaces the ZMI tab is
> broken: It uses datetime objects instead of DateTime objects and mixes
> them with existing DateTime settings.
> Last week I reviewed parts of the new code and fixed some small issues.
> But the bigger issues still exist. Based on what I encountered I wrote
> this small guide:
> http://svn.zope.org/*checkout*/CMF/trunk/CODINGSTYLE.txt
> Please keep the the trunk stable and use your own branch for unfinished
> changes.

I think this applies almost entirely to my work on browser views. Yuppie's
been in touch with me privately but I haven't found time to do the tidying
up.

I agree with nearly all the points. I'm not certain that SchemaAdapters
are always necessary. In my defence I hope it's worth noting that we now
have tests for a heap of stuff in CMFDefault which previously didn't exist.

Regarding SyndicationInfo - I'd appreciate any pointers on writing a
migration step. Given the hopelessly outdated state of the current
implementation I'm not convinced anyone will need to do the migration but
then, of course, one of the aims of CMFDefault is to provide exactly this
kind of example.

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 [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


y.2011 at wcm-solutions

Jan 27, 2011, 8:05 AM

Post #3 of 17 (2334 views)
Permalink
Re: [dev] working on the trunk [In reply to]

Hi Charlie!


Charlie Clark wrote:
> Am 26.01.2011, 16:50 Uhr, schrieb yuppie<y.2011 [at] wcm-solutions>:
>
>> I'm not happy with the current state of CMF trunk. Especially the
>> syndication related changes cause trouble in different ways:
>> - SyndicationInformation was replaced by SyndicationInfo without
>> providing migration code. Local syndication settings get lost in
>> existing sites.
>> - In the ZMI the SyndicationTool no longer has a tab that allows to
>> inspect and modify tool settings. The form that replaces the ZMI tab is
>> broken: It uses datetime objects instead of DateTime objects and mixes
>> them with existing DateTime settings.
>> Last week I reviewed parts of the new code and fixed some small issues.
>> But the bigger issues still exist. Based on what I encountered I wrote
>> this small guide:
>> http://svn.zope.org/*checkout*/CMF/trunk/CODINGSTYLE.txt
>> Please keep the the trunk stable and use your own branch for unfinished
>> changes.
>
> I think this applies almost entirely to my work on browser views. Yuppie's
> been in touch with me privately but I haven't found time to do the tidying
> up.
>
> I agree with nearly all the points. I'm not certain that SchemaAdapters
> are always necessary.

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.

> In my defence I hope it's worth noting that we now
> have tests for a heap of stuff in CMFDefault which previously didn't exist.
>
> Regarding SyndicationInfo - I'd appreciate any pointers on writing a
> migration step. Given the hopelessly outdated state of the current
> implementation I'm not convinced anyone will need to do the migration

What was wrong with the old implementation? I never had trouble using
the old configuration objects and forms. The old RSS template didn't
work for me, but that's a different issue.

> but
> then, of course, one of the aims of CMFDefault is to provide exactly this
> kind of example.

I'm sure I'm not the only one who has existing CMF sites with
SyndicationInformation objects in it. Making sure these sites can be
upgraded without trouble is essential. And not a nice to have extra.
Especially if the old implementation did work and the new one doesn't
provide any new features.


Cheers,

Yuppie
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


charlie.clark at clark-consulting

Sep 28, 2011, 2:57 PM

Post #4 of 17 (2020 views)
Permalink
Re: [dev] working on the trunk [In reply to]

Am 27.01.2011, 17:05 Uhr, schrieb yuppie <y.2011 [at] wcm-solutions>:

> 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. :-/

>> In my defence I hope it's worth noting that we now
>> have tests for a heap of stuff in CMFDefault which previously didn't
>> exist.
>>
>> Regarding SyndicationInfo - I'd appreciate any pointers on writing a
>> migration step. Given the hopelessly outdated state of the current
>> implementation I'm not convinced anyone will need to do the migration

> What was wrong with the old implementation? I never had trouble using
> the old configuration objects and forms. The old RSS template didn't
> work for me, but that's a different issue.

I think the old implementation was just wrong headed to use SimpleItem for
this. But think I've worked out how to do the migration.

>> but
>> then, of course, one of the aims of CMFDefault is to provide exactly
>> this
>> kind of example.
> I'm sure I'm not the only one who has existing CMF sites with
> SyndicationInformation objects in it. Making sure these sites can be
> upgraded without trouble is essential. And not a nice to have extra.
> Especially if the old implementation did work and the new one doesn't
> provide any new features.

I agree that a migration step is necessary and will put one in.

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 [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


y.2011 at wcm-solutions

Sep 29, 2011, 1:39 AM

Post #5 of 17 (2016 views)
Permalink
Re: [dev] working on the trunk [In reply to]

Hi Charlie!


Charlie Clark wrote:
> Am 27.01.2011, 17:05 Uhr, schrieb yuppie<y.2011 [at] wcm-solutions>:
>
>> 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 [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


charlie.clark at clark-consulting

Sep 29, 2011, 3:16 AM

Post #6 of 17 (2021 views)
Permalink
Re: [dev] working on the trunk [In reply to]

Hi Yuppie,

thanks as ever for the helpful explanation.

Am 29.09.2011, 10:39 Uhr, schrieb yuppie <y.2011 [at] wcm-solutions>:

> 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 [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


y.2011 at wcm-solutions

Sep 29, 2011, 5:14 AM

Post #7 of 17 (2014 views)
Permalink
Re: [dev] working on the trunk [In reply to]

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 [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


charlie.clark at clark-consulting

Sep 29, 2011, 10:53 AM

Post #8 of 17 (2012 views)
Permalink
Re: [dev] working on the trunk [In reply to]

Am 29.09.2011, 14:14 Uhr, schrieb yuppie <y.2011 [at] wcm-solutions>:

> 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 [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


y.2011 at wcm-solutions

Sep 30, 2011, 1:55 AM

Post #9 of 17 (2011 views)
Permalink
Re: [dev] working on the trunk [In reply to]

Hi Charlie!


Charlie Clark wrote:
> 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.

If you want to modernize SyndicationInformation, why do you still store
DateTime objects in the database? (And why don't you use zope.annotation?)

Quoting the docstring of schema.py: "SchemaAdapterBase and
ProxyFieldProperty are legacy code. They should only be used to adapt
old content types that can't handle unicode and datetime correctly."

AFAICS only the getUpdateBase method of ISyndicationTool needs to be
backwards compatible. Everything else is new API or doesn't return
DateTime objects. Wouldn't it be better to use datetime internally? You
already need an upgrade step for SyndicationInformation. Writing an
additional upgrade step for SyndicationTool wouldn't be much extra work.


Cheers,

Yuppie
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


charlie.clark at clark-consulting

Sep 30, 2011, 11:32 AM

Post #10 of 17 (2003 views)
Permalink
Re: [dev] working on the trunk [In reply to]

Hiya yuppie,

Am 30.09.2011, 10:55 Uhr, schrieb yuppie <y.2011 [at] wcm-solutions>:

> If you want to modernize SyndicationInformation, why do you still store
> DateTime objects in the database? (And why don't you use
> zope.annotation?)

I think that when I started this I was initially trying to update the
syndication stuff and practise writing tests by filling out the missing
blanks. It then snowballed with my views work. You're right, of course,
that having removing the ZMI interface to SyndicationInfo I've got more
control over how stuff was stored. I need to revisit the zope.annotation
docs but the last time I looked it didn't offer much.

> Quoting the docstring of schema.py: "SchemaAdapterBase and
> ProxyFieldProperty are legacy code. They should only be used to adapt
> old content types that can't handle unicode and datetime correctly."

What? You think I'm going to start reading the code? ;-) Having got Site
Syndication licked I thought I could consolidate the view code. How wrong
I was!

> AFAICS only the getUpdateBase method of ISyndicationTool needs to be
> backwards compatible. Everything else is new API or doesn't return
> DateTime objects. Wouldn't it be better to use datetime internally? You
> already need an upgrade step for SyndicationInformation. Writing an
> additional upgrade step for SyndicationTool wouldn't be much extra work.

Right. BTW. anyone know of an OFS implementation of os.walk? There used to
be zwalk but I think it's disappeared behind the Google horizon.

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 [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


tseaver at palladion

Sep 30, 2011, 1:29 PM

Post #11 of 17 (1998 views)
Permalink
Re: [dev] working on the trunk [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/30/2011 02:32 PM, Charlie Clark wrote:
> Hiya yuppie,
>
> Am 30.09.2011, 10:55 Uhr, schrieb yuppie
> <y.2011 [at] wcm-solutions>:
>
>> If you want to modernize SyndicationInformation, why do you still
>> store DateTime objects in the database? (And why don't you use
>> zope.annotation?)
>
> I think that when I started this I was initially trying to update
> the syndication stuff and practise writing tests by filling out the
> missing blanks. It then snowballed with my views work. You're
> right, of course, that having removing the ZMI interface to
> SyndicationInfo I've got more control over how stuff was stored. I
> need to revisit the zope.annotation docs but the last time I looked
> it didn't offer much.
>
>> Quoting the docstring of schema.py: "SchemaAdapterBase and
>> ProxyFieldProperty are legacy code. They should only be used to
>> adapt old content types that can't handle unicode and datetime
>> correctly."
>
> What? You think I'm going to start reading the code? ;-) Having got
> Site Syndication licked I thought I could consolidate the view
> code. How wrong I was!
>
>> AFAICS only the getUpdateBase method of ISyndicationTool needs to
>> be backwards compatible. Everything else is new API or doesn't
>> return DateTime objects. Wouldn't it be better to use datetime
>> internally? You already need an upgrade step for
>> SyndicationInformation. Writing an additional upgrade step for
>> SyndicationTool wouldn't be much extra work.
>
> Right. BTW. anyone know of an OFS implementation of os.walk? There
> used to be zwalk but I think it's disappeared behind the Google
> horizon.

You want 'container.ZopeFind' or 'container.ZopeFindAndApply'.



Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver [at] palladion
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6GJpIACgkQ+gerLs4ltQ6igACgm2HLFUDCzhmi+J1y3uBeVYaV
6a0AniWMsy+5Lb5M4Z3YW2/50ZATWZbh
=sVCd
-----END PGP SIGNATURE-----

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


charlie.clark at clark-consulting

Oct 1, 2011, 5:36 AM

Post #12 of 17 (1994 views)
Permalink
Re: [dev] working on the trunk [In reply to]

Am 30.09.2011, 10:55 Uhr, schrieb yuppie <y.2011 [at] wcm-solutions>:

>
> AFAICS only the getUpdateBase method of ISyndicationTool needs to be
> backwards compatible. Everything else is new API or doesn't return
> DateTime objects. Wouldn't it be better to use datetime internally? You
> already need an upgrade step for SyndicationInformation. Writing an
> additional upgrade step for SyndicationTool wouldn't be much extra work.

ISyndicationInfo is a new interface. I'm tempted to use zope.schema
directly on this but I suppose that does tie any implementation to
zope.schema rather maybe annotated Python tyes. Thoughts?

Regarding zope.annotation - IAttributeAnnotatable creates a new object
within the folder but I'd rather not have the SyndicationInfo visible
within the ZMI but IAnnotations only uses a dictionary and so less
suitable for storing multiple values. If I go the AttributeAnnotatable way
is it okay to use Persistent rather than SimpleItem as long as
manage_fixupOwnershiAafterAdd is provided? Or is that too kludgy and
preferable to work on my current adapter to provide attribute access to an
Annotations dictionary?

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 [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


charlie.clark at clark-consulting

Oct 1, 2011, 5:36 AM

Post #13 of 17 (2002 views)
Permalink
Re: [dev] working on the trunk [In reply to]

Am 30.09.2011, 22:29 Uhr, schrieb Tres Seaver <tseaver [at] palladion>:

>
> You want 'container.ZopeFind' or 'container.ZopeFindAndApply'.

Thanks Tres!

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 [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


y.2011 at wcm-solutions

Oct 4, 2011, 1:55 AM

Post #14 of 17 (1949 views)
Permalink
Re: [dev] working on the trunk [In reply to]

Hi Charlie!


Charlie Clark wrote:
> Am 30.09.2011, 10:55 Uhr, schrieb yuppie<y.2011 [at] wcm-solutions>:
>
>>
>> AFAICS only the getUpdateBase method of ISyndicationTool needs to be
>> backwards compatible. Everything else is new API or doesn't return
>> DateTime objects. Wouldn't it be better to use datetime internally? You
>> already need an upgrade step for SyndicationInformation. Writing an
>> additional upgrade step for SyndicationTool wouldn't be much extra work.
>
> ISyndicationInfo is a new interface. I'm tempted to use zope.schema
> directly on this but I suppose that does tie any implementation to
> zope.schema rather maybe annotated Python tyes. Thoughts?

I think in general it's fine to use zope.schema for CMFCore interfaces.
But if you use properties instead of separate accessors and mutators,
you can't set different read/write permissions in Zope 2. So please make
sure modifying the settings is protected sufficiently.

> Regarding zope.annotation - IAttributeAnnotatable creates a new object
> within the folder

Why do you think so? AFAICS the default implementation stores all
annotations in the __annotations__ attribute.

> but I'd rather not have the SyndicationInfo visible
> within the ZMI but IAnnotations only uses a dictionary and so less
> suitable for storing multiple values. If I go the AttributeAnnotatable way
> is it okay to use Persistent rather than SimpleItem as long as
> manage_fixupOwnershiAafterAdd is provided? Or is that too kludgy and
> preferable to work on my current adapter to provide attribute access to an
> Annotations dictionary?

Cheers,

Yuppie
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


charlie.clark at clark-consulting

Oct 5, 2011, 3:07 AM

Post #15 of 17 (1943 views)
Permalink
Re: [dev] working on the trunk [In reply to]

Am 04.10.2011, 10:55 Uhr, schrieb yuppie <y.2011 [at] wcm-solutions>:

> I think in general it's fine to use zope.schema for CMFCore interfaces.
> But if you use properties instead of separate accessors and mutators,
> you can't set different read/write permissions in Zope 2. So please make
> sure modifying the settings is protected sufficiently.

Right, thanks for the reminder. Currently I have a schema in CMFDefault
derived from a very abstract interface in CMFCore and I think I'll stick
with that because I use a CMFDefault specific SimpleVocabulary.

>> Regarding zope.annotation - IAttributeAnnotatable creates a new object
>> within the folder
> Why do you think so? AFAICS the default implementation stores all
> annotations in the __annotations__ attribute.

Running some tests with the most recent version and it definitely creates
child objects that are visible in the ZMI. I guess I need to test this a
bit more but I suspect I might have to provide my own implementation.

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 [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


y.2011 at wcm-solutions

Oct 5, 2011, 6:26 AM

Post #16 of 17 (1942 views)
Permalink
Re: [dev] working on the trunk [In reply to]

Charlie Clark wrote:
> Am 04.10.2011, 10:55 Uhr, schrieb yuppie<y.2011 [at] wcm-solutions>:
>>> Regarding zope.annotation - IAttributeAnnotatable creates a new object
>>> within the folder
>> Why do you think so? AFAICS the default implementation stores all
>> annotations in the __annotations__ attribute.
>
> Running some tests with the most recent version and it definitely creates
> child objects that are visible in the ZMI. I guess I need to test this a
> bit more but I suspect I might have to provide my own implementation.

Strange! Your container implements IAttributeAnnotatable and
AttributeAnnotations is registered correctly?

Are you trying to use zope.annotation.factory? Last time I checked that
didn't work with Zope 2. But the AttributeAnnotations adapter works for
me without showing anything in the ZMI.

Cheers, Yuppie
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


charlie.clark at clark-consulting

Oct 5, 2011, 9:04 AM

Post #17 of 17 (1944 views)
Permalink
Re: [dev] working on the trunk [In reply to]

Am 05.10.2011, 15:26 Uhr, schrieb yuppie <y.2011 [at] wcm-solutions>:

> Strange! Your container implements IAttributeAnnotatable and
> AttributeAnnotations is registered correctly?

Yes, I was working with objects that provided things explicitly.

> Are you trying to use zope.annotation.factory? Last time I checked that
> didn't work with Zope 2. But the AttributeAnnotations adapter works for
> me without showing anything in the ZMI.

That's probably the problem - I was following the documentation which
suggests using zope.annotation.factory.

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 [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Zope cmf RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.