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