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 <richard_gor...@verizon.net> 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.
