This is a breaking change I support. For other UI widgets like the text widget, the default behaviour is not to submit any value during a form submit without explicit user input. It makes sense to align the default behaviour of other UI widgets as much as possible to the same.
When other frameworks like the .Net framework have a breaking change, they: - bump up the version number - publicise and document the breaking change(s) - support the older framework for a period for security updates I don't know if that exact arrangement would be suitable for web2py, but I wonder if there is anything else that could be done to help existing framework users when there is a breaking change, but they want to keep up with the latest web2py developments? One thought: Is it possible to construct a w2p plugin holding global overrides for all other web2py applications installed in that instance? That way existing code could keep the zero=None behaviour. On a clean-machine web2py install, one would just have to also install the plugin. I'm aware in this particular case the edits required to add zero=None to an db.py are minor. However in the general case we already have this really nice framework update mechanism going , just download latest web2py zip -> deploy, it is even built into the admin website. It would be great to make breaking changes just as easy to deal with, hence my suggestion of a compatibility plugin. - Alex On Mar 22, 9:01 am, ls1 <ls1.luk...@gmail.com> wrote: > For me it doesn't really matter what is default behaviour, > as long as it is documented. > Since I use zero='None' mostly, so change will not affect me much. > > But I would to ask to document it in official web2py book anyway. > Please don't take for granted that all users frequently go for > epydocs > to study internals of validators to get understanding how optional > parameters work. > > They don't. > Instead they will go to web2py book, chapter 7.4 Validators, > see nothing of "zero= " parameter, use IS_IN_SET without > even knowing this option, build application... > and later get confused. > > regards, Lukasz > > On 22 Mar, 03:24, Thadeus Burgess <thade...@thadeusb.com> wrote: > > > > > More about "why" there are so many questions. > > > The first question gets us exactly what someone wants as a default > > option. This is a bi-polar measure, quickly getting a base response > > for what is wanted. > > > The second one drills down qualitatively why they support this. > > > The third reveals known cons of this as the default that the developer > > accepts as OK and is willing to accept or live with. > > > The first two scales reveal how often each of the options is used in > > their own apps. Mind, this is not a bi-polar measure (that is what the > > first question is for) > > > The second two scales reveal how they feel about each of them as the > > default functionality. Again, not bi-polar measures. > > > I will remove the questions about backwards compatibility as it is not > > relative to what I am trying to accomplish, and not a "fair" question. > > > The combination of these answers can give much insight as to why the > > community feels about one option or the other. > > > With the explanation of what these measures are for, I will re-open > > this in a new topic so that the measures cannot be skewed by > > pre-exposure to opinions expressed by those of us with high merit in > > the community (myself included). I WILL invalidate the current results > > taken (currently only 4), so I ask if those who have taken could > > please re-take the new one. I will be posting a new survey in 15 > > minutes, to give time for any additional suggested changes that should > > be made before data collection starts. > > > -Thadeus > > > On Sun, Mar 21, 2010 at 9:12 PM, Thadeus Burgess <thade...@thadeusb.com> > > wrote: > > > Ok, to add (or remove) questions I "should" invalidate all the current > > > results (4) and those "should" retake the survey. Also pre-exposure to > > > this thread can skew the results as there are those who will always > > > "follow" what others say on this thread just because of the merit this > > > person has in the community. > > > > -Thadeus > > > > On Sun, Mar 21, 2010 at 9:07 PM, mdipierro <mdipie...@cs.depaul.edu> > > > wrote: > > >> I agree with Mr. Freeze but changing it now may constitute a breaking > > >> a backward compatibility. > > >> After reading the survey it has a lot of questions and it may > > >> confusing to a lot of users. > > >> Bottom line: > > > >> zero='' is what we have now (vote for this if you do not want changes > > >> in your apps) > > >> zero=None is the change in behavior that Thadeus is proposing. It will > > >> change the way dropbox behave. It will eliminate the default empty > > >> option in the stopbox (vote this if you want the first alphabetical > > >> value to be selected by default). > > > >> Clarifications: the last question asks whether the current solution > > >> (since 1.5x.x I think) was a breaking of backward compatibily, not > > >> whether a change now should be a braking of backward compatibility. > > >> @Thadeus, if you ask one question, you should ask the other too. > > > >> Since there are quite a lot of questions I have to retreat what I > > >> said. I first want to read the answers and then decide what to do. I > > >> cannot automatically follow what majority wants since it is possible > > >> that people will make that case that change of behavior now will > > >> constitute breaking of backward compatibility. > > > >> Massimo > > > >> On Mar 21, 8:49 pm, "mr.freeze" <nat...@freezable.com> wrote: > > >>> Done. I personally prefer zero='' as a default. I think the selection > > >>> should be made explicitly by the user unless an actual default value > > >>> for the field is set. This doesn't break backwards compatibility IMO > > >>> because web2py wasn't controlling it before, the browser was. > > > >>> On Mar 21, 8:26 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > > > >>> > That is not a good point. That is a interface and usability question, > > >>> > also it is a clientell question of who will be using the app. > > > >>> > I am tired of arguing this matter. As far as I see it, we broke > > >>> > backwards compatibility, forcing me to update all of my apps. > > > >>> > I respectfully ask the community to please take the following > > >>> > anonymous survey on this topic. I will support the outcome of the > > >>> > results for this survey as the community decision. > > > >>> > I will not take part of this survey since I created it. > > > >>> >https://spreadsheets.google.com/viewform?formkey=dE5pd01zNndEMk4zREpF... > > > >>> > -Thadeus > > > >>> > On Sun, Mar 21, 2010 at 7:55 PM, mdipierro <mdipie...@cs.depaul.edu> > > >>> > wrote: > > >>> > > Not everybody agreed. Somebody (do not remember who) made a good > > >>> > > point > > >>> > > that having zero=None will case people to fill forms with with wrong > > >>> > > values (always the first alphabetical value). > > > >>> > > On Mar 21, 7:21 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > > >>> > >> Massimo, I think in the post everyone agreed to make zero=None the > > >>> > >> default, and yet after at least 13 of us said to make this the > > >>> > >> default, nothing happened. The original design was (is) a good > > >>> > >> idea, > > >>> > >> but making that a default was a bad idea. Nobody had any input at > > >>> > >> the > > >>> > >> moment, but after playing around with it, it sucks being the > > >>> > >> default. > > > >>> > >> -Thadeus > > > >>> > >> On Sun, Mar 21, 2010 at 1:00 PM, mdipierro > > >>> > >> <mdipie...@cs.depaul.edu> wrote: > > >>> > >> > There was a long discussion about this. Different people > > >>> > >> > disagreed on > > >>> > >> > how this should behave. > > > >>> > >> > You can revert to the previous behavior with > > > >>> > >> > IS_IN_SET(...,zero=None) > > >>> > >> > IS_IN_DB(...,zero=None) > > > >>> > >> > Or customize the empty value > > > >>> > >> > zero="Please choose one" > > > >>> > >> > Massimo > > > >>> > >> > On Mar 21, 12:42 pm, annet <annet.verm...@gmail.com> wrote: > > >>> > >> >> Today, I upgraded my web2py installation to version 1.76.5. In > > >>> > >> >> this > > >>> > >> >> web2py version the drop boxes display an empty key value pair > > >>> > >> >> first, > > >>> > >> >> and then the key value pairs from the tables I based them on. > > >>> > >> >> What > > >>> > >> >> causes this change in behaviour? How do I correct it? > > > >>> > >> >> Kind regards, > > > >>> > >> >> Annet. > > > >>> > >> > -- > > >>> > >> > You received this message because you are subscribed to the > > >>> > >> > Google Groups "web2py-users" group. > > >>> > >> > To post to this group, send email to web...@googlegroups.com. > > >>> > >> > To unsubscribe from this group, send email to > > >>> > >> > web2py+unsubscr...@googlegroups.com. > > >>> > >> > For more options, visit this group > > >>> > >> > athttp://groups.google.com/group/web2py?hl=en. > > > >>> > > -- > > >>> > > You received this message because you are subscribed to the Google > > >>> > > Groups "web2py-users" group. > > >>> > > To post to this group, send email to web...@googlegroups.com. > > >>> > > To unsubscribe from this group, send email to > > >>> > > web2py+unsubscr...@googlegroups.com. > > >>> > > For more options, visit this group > > >>> > > athttp://groups.google.com/group/web2py?hl=en. > > > >> -- > > >> You received this message because you are subscribed to the Google > > >> Groups "web2py-users" group. > > >> To post to this group, send email to web...@googlegroups.com. > > >> To unsubscribe from this group, send email to > > >> web2py+unsubscr...@googlegroups.com. > > >> For more options, visit this group > > >> athttp://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
