RE: [Zope-dev] broken selection property support in z2.2
I tried creating a zclass that had a property sheet with a selection type, which i had reference a property of a given name. I then went to the root folder in zope and created that property as a lines type. When i created an instance of my zclass though, it said "no value for given_name". To fix this i changed the OFS/properties.dtml file to use the same syntax as the properties.dtml in z2.1:
<dtml-elif "type=='selection'"> <dtml-if "_.has_key(select_variable)"> <select name="<dtml-var id>"> <dtml-in "_[select_variable]">
It used to use hasProperty and getProperty methods. I'm not entirely sure why they were used, or what they are suppose to do differently, but it doesn't seem to work.
Scott, 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. Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
OIC, thanks for the clerification on that. sRp Thus spake Brian Lloyd (Brian@digicool.com):
I tried creating a zclass that had a property sheet with a selection type, which i had reference a property of a given name. I then went to the root folder in zope and created that property as a lines type. When i created an instance of my zclass though, it said "no value for given_name". To fix this i changed the OFS/properties.dtml file to use the same syntax as the properties.dtml in z2.1:
<dtml-elif "type=='selection'"> <dtml-if "_.has_key(select_variable)"> <select name="<dtml-var id>"> <dtml-in "_[select_variable]">
It used to use hasProperty and getProperty methods. I'm not entirely sure why they were used, or what they are suppose to do differently, but it doesn't seem to work.
Scott,
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.
Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
-- Scott Parish http://srparish.net
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
participants (3)
-
Brian Lloyd -
R. David Murray -
Scott Parish