Hi Thadeus. You have two objections. One is procedural and one is more substantial.
Procedurally, I can add any feature I consider appropriate. It has happened before. It will happen again. In practice, it is my interest to keep users happy and in particular other contributors, so if I feel something is contentious, I do ask for people opinion. It have done so and I will continue to do so. And if I do not ask, you can bring it up. And you did well to bring this up. Now to the substantial objection. The change in question was made because I thought it was a good one (and I still think so), because it did not break backward compatibility (no application broke, it just caused more error messages when users failed to select a value in dropbox). Moreover at the time I did not think it was not going to be so contentious. I am not yet even sure it is contentious now, that is what you have to prove with the poll. Changing it back is more problematic because it will cause users to accidentally submit forms with default options chosen by the browser instead of chosen by the programmer or the user (if no default=... is set, the browser will automatically select the first item in the options). In my view that is bad software design so it shoud stay as it is. There a number resources on the web that give practial recommendations. For example http://www.cs.tut.fi/~jkorpela/forms/choices.html says "For a normal 1-of-many selection (apart from the two preceding cases), use either a SELECT element or a set of radio buttons. In both cases, make sure a well-defined default is initially selected". zero='' provides that option for create forms. Nevertheless, I do accept the possibility that I am wrong. I have been wrong before. Yet you have to prove to me that I am wrong. I understand your case and that is not sufficient. I need to know that a good majority of the people think that this should be reverted. For me, backward compatibility means that we do not introduce changes that break web2py APIs as documented in published book. For example I have said over and over that the new DAL may break SQLCustomType because will hopefully provide a better mechanism. So let me add something new to the discussion: You mentioned difficulty in changing back the behavior of your apps. Here is a simple solution for that. In your db.py, before you use IS_IN_DB: IS_IN_DB2 = IS_IN_DB def IS_IN_DB(*a,**b): b['zero']=None return IS_IN_DB2(*a,**b) (and same for IS_IN_SET). With this piece of code your apps will behave as if this change was never introduced and you will not need to edit it. People who like a message can do: IS_IN_DB2 = IS_IN_DB def IS_IN_DB(*a,**b): b['zero']=T('please choose one') return IS_IN_DB2(*a,**b) Anyway. I really think the poll should have a deadline. How many votes do you have so far? When are you planning to close it? Massimo On Mar 24, 10:21 pm, Thadeus Burgess <[email protected]> wrote: > I am not sure of the exact time frame that this was introduced > (zero='', breaking backwards-compatibility) by it was only a matter of > a couple of months ago, not a year. The exact date was "2010-01-03" of > this change, > athttp://bazaar.launchpad.net/~mdipierro/web2py/devel/revision/1497 > > Should I point out that > > A) This was at a time when most who would have had input on this were > on holiday break, and > B) hardly enough time has passed for all community members to properly > test this and > C) I am unable to find a post about proposing the change from > zero=None to zero='choose a value'. I have searched my GMail archive, > as well as the online google groups, and have not found this > documented, I take this to mean it "creeped" in without community > approval. > D) Must I must I must I resurrect the many posts about this? Massimo, > do a search for zero in the groups, read the posts there is ample > proof of zero=None being an issue. > E) There has been more arguments raised by the community against > zero='' than there has been for zero=''. Refer to item D for > statistics. > F) Must I also point out that this feature was added about a year ago, > and lived as zero=None for approx. 9 months before the change to > zero=''. > > This is why the rapid release development of web2py is bad, we never > get a chance to test these features properly in many environments > before they are set in stone and made backwards compatible. > > Perhaps there should be a time to live (TTL) for new features and > their default settings? If a new feature is implemented, put it on a 6 > month TTL, if by the close of 6 months it has been stable, then add it > as part of the backwards compatibility agreement. This gives ample > time for testing by the whole of the community and all who use this > lovely framework, whilst still following a rapid-release cycle that > has been adopted. > > * I am still waiting for a operation definition of backwards compatibility * > > -Thadeus > > On Wed, Mar 24, 2010 at 10:20 AM, mdipierro <[email protected]> wrote: > > It is not that simple. zero='' was introduced about one year ago > > because of popular demand at the time and very few people spoke > > against it. If you change it now you revert to the behavior you had > > one year ago but most recent applications will change behavior. > > > This consultation should have a deadline. > > > Massimo > > > On Mar 24, 9:43 am, Iceberg <[email protected]> wrote: > >> On Mar23, 2:29pm, weheh <[email protected]> wrote: > > >> > Thadeus, it's 6 of one, half-dozen of the other to me. I use both. So > >> > in theory, it doesn't really matter which is the default. Therefore, I > >> > prefer that the default remain whatever it currently is so that I > >> > don't have to change any of my code. > > >> To those who use either zero=None or zero='' fifty-fifty, or who > >> always specify zero=something explicitly, > > >> Congratulations, because you are lucky enough that you don't need to > >> care the vote result very much. However, in this case, it is not about > >> what you choose, it is about what you believe. > > >> First of all, we should know that it was zero=None at the very > >> beginning when this feature was invented. Somehow, later it changed to > >> zero='' or zero='something else' back and forth. > > >> Now, do you believe, from the backward-compatible point of view, we > >> should choose a default value which is compatible with the old > >> versions even without zero=... being invented? If you do believe, you > >> should choose zero=None. > > >> Do you believe, from a minimum-changing-code point of view, this > >> efficiency appeal should not only apply for you, whom might > >> coincidentally start using web2py after it is in zero!=None era, but > >> also apply for all the developers whom already finish more or less > >> legacy apps even before the zero=... was invented? If you do believe, > >> you should choose zero=None. > > >> Do you believe, from a community point of view, we should not allow > >> such a precedent that, an arguable and non-backward-compatible feature > >> creep in, and then stay as-is just because "it already happen anyway"? > >> That is not wise. If you do believe, you should choose zero=None. > > >> It is now! Let's just end the debate. > >> I want you to > >> vote.http://www.collegelax.us/news/wp-content/uploads/2009/01/i-want-you-t... > > >> Sincerely, > >> Iceberg > > > -- > > You received this message because you are subscribed to the Google Groups > > "web2py-users" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
