On 17 Jan 2006, at 10:28, yuppie wrote:
Florent Guillaume wrote:
Florent Guillaume wrote:
I recently introduced the fact that in extension profiles list properties aren't purged by default. But really this introduces problems, as if you simply import an extension profile twice you'll get all you lists doubled.

So I think I'll use the opposite semantic, closer to what was the case before: purge by default for lists even in extension profiles, except if purge="False" is present on the property.
I checked this in.
But actually this revealed what I think is slightly unclear behaviour in the case of loading extension profiles: the extension profile can happily modify objects without them being purged, but I believe that as soon as it has to create a new object, the import context should be switched to _should_purge=True for that object and the recursion inside it.
What do you think?

I don't like that idea:

- Applying the settings to a new object should always have the same result as applying them to a purged object. If everything is implemented that way changing the purge mode to True doesn't make any difference in deeper levels.

- You would need a way to mark those parts of the extension profile that should always create new objects (or purge them if they already exist). We already have purge="True" for that.

- I can't see how this would resolve your issue for purge="False".

The handlers for other sequences (like skin paths and object managers) just add new sequence items if the item doesn't exist already. Wouldn't that also work for list properties?

Yes but other sequences have an implicit semantics which is that elements cannot appear twice. Whereas here for properties that are lists we don't know the underlying semantics. It could be desired or not to have an element present twice. Not in my use case admittedly, but you never know.

Up to know I just added elements to the list, without removing identical ones already present.

What I can do is, for now, make purge=False have the exact semantics than for skins or objects (remove the old element first if it exists), but we know that at some point we may have to extend that semantic to provide things like append="True" or append="always" and append="once"... We can probably avoid deciding that now.


Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]

Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to