[Zope-dev] Re: Collector 697 should be critical!!!

[Toby Dickenson]

from ages ago....

> > > In OFS/dtml/properties.dtml I replaced
> > >
> > >   <select name=3D"xyz:utf8:list" multiple>
> > >
> > > with:
> > >
> > >   <select name=3D"xyz:utf8:list:string" multiple>
> > >
> > > It works for me, but I'm not sure, if this is a good approach on th=
is
> > > problem (think of the integers as items for the multiple-select).
> >
> > I havent looked in detail yet, but my first impression is that this i=
s 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 value=
s
> 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 lik=
e
> [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 thin=
k
> 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 ul=
ines=20
without risking breaking old code.

Something like your suggested improvement would be one way to improve thi=
s. I=20
think this would make a good fishbowl proposal

--=20
Toby Dickenson
http://www.geminidataloggers.com/people/tdickenson