Collector 697 should be critical!!!
Hi, http://collector.zope.org/Zope/697 should be set to critical, because it results in loosing essential data. Case: We store much of our "Keywords" etc. in multiple-selects. Everytime a user edits and saves such a multiple-select, all items with NON-Ascii-characters [german umlaute for example] won't be shown as selected cause of the bug. So the next "Save Changes" will loose all this items. I don't know where's the best place to fix this issue, but it need to be fixed as soon as possible... Cheers, Maik
If this is critical for you, then you will probably need to develop a patch for it in order for it to make it into 2.6.1; unless anyone else wants to volunteer. I don't feel comfortable enough with the unicode converters to do this. -Casey On Monday 02 December 2002 05:46 am, Maik Jablonski wrote:
Hi,
http://collector.zope.org/Zope/697
should be set to critical, because it results in loosing essential data.
Case: We store much of our "Keywords" etc. in multiple-selects. Everytime a user edits and saves such a multiple-select, all items with NON-Ascii-characters [german umlaute for example] won't be shown as selected cause of the bug. So the next "Save Changes" will loose all this items.
I don't know where's the best place to fix this issue, but it need to be fixed as soon as possible...
Cheers, Maik
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Casey Duncan wrote:
If this is critical for you, then you will probably need to develop a patch for it in order for it to make it into 2.6.1; unless anyone else wants to volunteer. I don't feel comfortable enough with the unicode converters to do this.
For me it's critical, but maybe for others too who haven't even noticed the problem. They loose content everytime someone "Save Changes" on a PropertyTab with multiple-selects... That's why I'm thinking that this bug should be marked as critial. I don't have much experience with the unicode-converters too... that's my problem for this issue...:-( Abel Deuring told me a patch, which solves the problem in the meanwhile: In OFS/dtml/properties.dtml I replaced <select name="xyz:utf8:list" multiple> with: <select name="xyz:utf8:list:string" multiple> It works for me, but I'm not sure, if this is a good approach on this problem (think of the integers as items for the multiple-select). -mj
On Monday 02 December 2002 4:11 pm, Maik Jablonski wrote:
I don't have much experience with the unicode-converters too... that's my problem for this issue...:-(
I had seen this bug on the list, but hant spotted that it was a unicode-related. I will try to take a look sometime this week.
Abel Deuring told me a patch, which solves the problem in the meanwhile:
In OFS/dtml/properties.dtml I replaced
<select name="xyz:utf8:list" multiple>
with:
<select name="xyz:utf8:list:string" multiple>
It works for me, but I'm not sure, if this is a good approach on this problem (think of the integers as items for the multiple-select).
I havent looked in detail yet, but my first impression is that this is a good approach.
Toby Dickenson wrote:
On Monday 02 December 2002 4:11 pm, Maik Jablonski wrote:
I don't have much experience with the unicode-converters too... that's my problem for this issue...:-(
I had seen this bug on the list, but hant spotted that it was a unicode-related. I will try to take a look sometime this week.
Abel Deuring told me a patch, which solves the problem in the meanwhile:
In OFS/dtml/properties.dtml I replaced
<select name="xyz:utf8:list" multiple>
with:
<select name="xyz:utf8:list:string" multiple>
It works for me, but I'm not sure, if this is a good approach on this problem (think of the integers as items for the multiple-select).
I havent looked in detail yet, but my first impression is that this is a good approach.
Well, I think that this is just a workaround, but not a bugfix ;) Assume that ulines property is used to define the set of possible values for a multiple selection property. In this case one would expect to get a ustring vaule back. And as Maik already mentioned, it is even possible to use something like [1, 2, 3,4] as the possible values of the multiple selection . OK, this case does not work very well with older version of Zope too, but I think that this shows the general problem: Currently (including older Zope versions), there absolutely no type conversion for multiple selections. My idea of a proper fix is to add a method to the PropertyManager which returns the type of the first element of the list of the allowed values. As a very trivial and not very elegant approach (sorry, I don't much time at present;): def type_as_string(self, selectValues): if type(selectValues[0]) == type(''): return 'string' elif type(selectValues[0]) == type(u''): return 'ustring' elif type(selectValues[0]) == type(0): return 'int' elif .... With this method available, the multiple selection part of OFS/dtml/properties.dtml could be changed from: <select name="<dtml-var id>:utf8:list" multiple size="<dtml-var "_.min(7, _.len(_[select_variable]))">"> to: <select name="<dtml-var id>:utf8:list:<dtml-var "type_as_string(selectValues)">" multiple size="<dtml-var "_.min(7, _.len(_[select_variable]))">">
from ages ago....
In OFS/dtml/properties.dtml I replaced
<select name="xyz:utf8:list" multiple>
with:
<select name="xyz:utf8:list:string" multiple>
It works for me, but I'm not sure, if this is a good approach on this problem (think of the integers as items for the multiple-select).
I havent looked in detail yet, but my first impression is that this is a good approach.
Well, I think that this is just a workaround, but not a bugfix ;)
This patch was committed on bug day
Assume that ulines property is used to define the set of possible values for a multiple selection property. In this case one would expect to get a ustring vaule back.
And as Maik already mentioned, it is even possible to use something like [1, 2, 3,4] as the possible values of the multiple selection . OK, this case does not work very well with older version of Zope too, but I think that this shows the general problem: Currently (including older Zope versions), there absolutely no type conversion for multiple selections.
Correct. That means that "multiple selection" can never work 100% with ulines without risking breaking old code. Something like your suggested improvement would be one way to improve this. I think this would make a good fishbowl proposal -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
participants (4)
-
abel deuring -
Casey Duncan -
Maik Jablonski -
Toby Dickenson