On Tue, 27 Jun 2000, Brian Lloyd wrote:
> The 'selection' and 'multiple selection' properties are
> really built with the idea that you use another property
> *of the same object* (rather than an acquired value) to
> bind the selection to. Your change works for your case,
> but if you try to bind to another property of the same
> ZClass you'll find that in your management screens that
> your selection property will fail (because it is looking
> in '_' for the value, which is the wrong place to look
> if you are expecting to find the value as another property
> of the same object.
It used to work both ways. I know because I first implemented
a selection property with another property on the same object,
and later moved it to a property on the root. I did this
because otherwise my custom Product add method couldn't
access the selection value property that was on the ZClass
property sheet. (I think I could probably figure out how
to make that access now, but then I couldn't).
Anyway, the point I'm leading up to is, if you ignore implementation
issues, isn't restricting the value field to being a property on
the same object being unecessarily restrictive? Surely there can
be cases where you want the value field to be acquirable. Of
course, there should be a way to specify that it be the same, for
cases where you *don't* want acquisition to work.
--RDM
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
