Re: [web2py] Re: Survey: Functionality of the Drop Boxes widget
Here are the results from two sources, A) The survey, and B) Listing
of community members speaking for one or the other.
A) Survey - 12 Responses ( No way to determine if anybody spammed responses )
There are no significant differences in usage scales, the hypothesis
is that it only matters for the kind of form, so 50% of the time
they are changing it one way or the other.
Preferences are split 50/50 for zero=None and zero="".
https://spreadsheets.google.com/ccc?key=0AstNNXQhkjU-dE9jS1VHSWdyd08xX2x6NU0yaEs1cnc&hl=en
B) Community Members
I have attached a OpenOffice document containing two columns. The
first column is of community members
speaking for zero=None as the default, along with the date and time.
This does not include any of my posts, though
I am a strong advocate of zero=None. The second column is of community
members arguing for zero="".
This is the general synopsis.
For Zero=""
Having zero=None represents a usability issue, assume the average user
is lazy(stupid) and provide a default
that does not validate, this is to keep them from accidentally
submitting a valid option they did not want.
For Zero=None
Change back to zero=None so old apps act the same, or they want it to
display without the blank option.
The blank option gives values that does not validate. It makes logical
sense to only have values
in the dropdown that validate. zero is an EXTRA feature and should be
turned on EXPLICITLY when needed
instead of turned OFF when not needed.
-Thadeus
On Thu, Mar 25, 2010 at 1:03 AM, mdipierro wrote:
> 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 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
Re: [web2py] Re: Survey: Functionality of the Drop Boxes widget
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, at http://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 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 wrote: >> On Mar23, 2:29pm, weheh 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 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. > > -- 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.
Re: [web2py] Re: Survey: Functionality of the Drop Boxes widget
It is not so trivial to search and replace. For one, you cannot place keyword arguments before non-keyword args. So it is not a simple matter of find/replace IS_IN_SET(... with IS_IN_SET(zero=None..., there will have to be parsing of the syntax to determine where to place zero=. I am perfectly capable of making the changes, and most likely will. Other frameworks, have version upgrades that happen once a month at the very least frequency, with migration guides, change logs, and previous version supported bug fixes. Web2py cannot do this, for one the development cycle is more along the lines of hours/days instead of months, there are no migration logs, there are no change logs, there is no point of reference for upgrading version to version. As I have asked before, if Massimo would place an operational definition of "backwards compatibility" in the context of web2py, otherwise it is open to interpretation, and will be judged as those interpretations are assumed. If you are going to set a standard and a promise, you either define the parameters of that standard, or uphold it to the highest and most rigid interpretations. Here we realize the reason for religious debate and war, the absence of scientific definitions that allow individuals from all walks of life to understand from the same perspective and context. My interpretation is of not having to change a line of code to upgrade my application and have it look _exactly_ the same after the upgrade. The majority of use cases is 50/50 and depends on the context of the form. Even for me, the use cases differ from hobby applications to professional applications. -Thadeus On Tue, Mar 23, 2010 at 2:54 AM, Yarko Tymciurak wrote: > Thadeus - > > I initially commiserated with you: "backward compatipility is > backward compatibility" --- but I alwasy thought Massimo held on to > that phrase too strongly, too tightly. It's important for the "big" > things, but it _always_ gets in the way of meaningful, useful > change... > > I think perhaps Massimo's bordering on being dogmatic about "backward > compatibiliy" may have an affect on how people react to this. > > But Jonathan gives an important insight: "I always specify zero=..." > > Even as "zero=..." didn't exist before, it's easy enough to do > globeal search and modify to put it in - it's _really_ not a big > deal; it's one of those things where dogmatically holding to the > "compatability principle" is more trouble than adapting to this > change. If it was happening all the time, often... this would be > annoying; but occasionally, it is more than tolerable - it can even > be a good thing, in the big scheme of things. > > You are, of course, free to see it in whatever way you happen to see > it. I'm just offering a summary of a counterpoint for consideration. > > Kind regards, > Yarko > > On Mar 23, 2:22 am, Thadeus Burgess wrote: >> weheh, Massimo, >> >> The issue is the same for me, I have several web2py applications, each >> commanding over 20 forms which make use of IS_IN_SET. I am dealing >> with a sizable number of forms that I need to update just to fix this. >> The fact is that web2py changed the output of how drop boxes are >> rendered, and in turn it has broken my forms that relied on the first >> element being selected. >> >> Aside from the time to alter my forms, this is an issue of promise, >> and principle that separate web2py from other python frameworks. To >> take a few quotes and give my interpretations of them. >> >> "" Another feature of web2py, is that we, its developers, commit to >> maintain backward compatibility in future versions. We have done so >> since the first release of web2py in October, 2007. New features have >> been added and bugs have been fixed, but if a program worked with >> web2py 1.0, that program will still work today. "" - Massimo Di >> Pierro, Web2py Book, Chapter 1, Introduction >> >> This is the kicker, my programs no longer "work" as intentionally >> designed. Perhaps you should re-word this as "will still >> compile/execute/not crash" instead of "work". >> >> ""web2py has never broken backwards compatibility, and it will not >> break compatibility when additional functionality is added in the >> future. "" - Massimo Di Pierro, Web2py Book, Chapter 1.4, Why Web2py >> >> The definition of compatibility is very loosely defined. This quote is >> in response to the one made that "web2py never controlled this before, >> now it is". Regardless of if web2py controlled something previously or >> not, it cannot change the compatibility with older versions. >> >> Given the scope of the web2py applications that I develop, and the >> sheer principle of the matter, do you understand where I am coming >> from? >> >> I seem to be left with the following options >> >> A) Update my 100+ forms and set zero=None. I view this as a complete >> waste of my time, either manually or working a search/replace and then >> re-testing all of my forms. >> B) Use a patched ve
Re: [web2py] Re: Survey: Functionality of the Drop Boxes widget
weheh, Massimo, The issue is the same for me, I have several web2py applications, each commanding over 20 forms which make use of IS_IN_SET. I am dealing with a sizable number of forms that I need to update just to fix this. The fact is that web2py changed the output of how drop boxes are rendered, and in turn it has broken my forms that relied on the first element being selected. Aside from the time to alter my forms, this is an issue of promise, and principle that separate web2py from other python frameworks. To take a few quotes and give my interpretations of them. "" Another feature of web2py, is that we, its developers, commit to maintain backward compatibility in future versions. We have done so since the first release of web2py in October, 2007. New features have been added and bugs have been fixed, but if a program worked with web2py 1.0, that program will still work today. "" - Massimo Di Pierro, Web2py Book, Chapter 1, Introduction This is the kicker, my programs no longer "work" as intentionally designed. Perhaps you should re-word this as "will still compile/execute/not crash" instead of "work". ""web2py has never broken backwards compatibility, and it will not break compatibility when additional functionality is added in the future. "" - Massimo Di Pierro, Web2py Book, Chapter 1.4, Why Web2py The definition of compatibility is very loosely defined. This quote is in response to the one made that "web2py never controlled this before, now it is". Regardless of if web2py controlled something previously or not, it cannot change the compatibility with older versions. Given the scope of the web2py applications that I develop, and the sheer principle of the matter, do you understand where I am coming from? I seem to be left with the following options A) Update my 100+ forms and set zero=None. I view this as a complete waste of my time, either manually or working a search/replace and then re-testing all of my forms. B) Use a patched version of web2py that does what I want, zero=None. This is not a desired option since keeping up with updates gets quite complex when branching the codebase (DVCS or not). A continuous waste of my time. C) Re-define IS_IN_SET in one of my models, however since web2py now assumes* requires, I need to make sure and define this for my foreign key relationships, since sql.py uses the imported version of IS_IN_SET instead of the global version. * I could also make the same argument for this as it did change the functionality of forms that used to render as text boxes but now render as select since they are FK relationships. -Thadeus On Tue, Mar 23, 2010 at 1:29 AM, weheh 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. > > -- > 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. > > -- 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.
Re: [web2py] Re: Survey: Functionality of the Drop Boxes widget
On Mar 22, 2010, at 10:16 PM, Thadeus Burgess wrote: > Just an update: > > The current functionality is set at zero="" for web2py. This survey > will only serve as a consulting referendum, it does not mean that the > end result will be the same. > > Current Number of responses: 5 (we really need more! everyone who uses > web2py can take apart of this!) (I think you meant: "a lot".) I didn't answer because my answer wasn't an option: I don't care what the default is because I always specify zero=. > > -Thadeus > > > > > > On Sun, Mar 21, 2010 at 10:06 PM, Thadeus Burgess > wrote: >> There is current on-going discussion of the default functionality of >> the drop boxes widget. This is an attempt to gather information from >> the community on this discussion. The results of this survey will >> determine what this default functionality will be. >> >> Here is the comparison of the two options currently being considered. >> >> zero="" >> >> This is when a drop box is rendered, there is an empty OPTION tag >> rendered in the first that is selected. >> >> zero=None >> >> This is when only the options in the list are rendered. The first >> option in the list is selected. >> >> https://spreadsheets.google.com/viewform?formkey=dE9jS1VHSWdyd08xX2x6NU0yaEs1cnc6MA >> >> Thank You, >> >> -Thadeus >> > > -- > 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. > -- 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.
