I totally agree Kevin. From the Zen of Python: "There should be one-- and preferably only one --obvious way to do it."
On Nov 6, 8:15 pm, Kevin <extemporalgen...@gmail.com> wrote: > Systems get harder to learn when there are seemingly multiple ways to > do things. It's not always clear that alternatives are really > optional, or if different parameter conventions are needed in > different situations. > > I had a little trouble learning parts of the DAL, for example, when > it's not clear which was required, and even which was preferred > between: > > db(mytable).select() > db.select(mytable.ALL) > > Yeah, one way to do things, even if it takes extra effort 20% of the > time, is probably better if you want new users to still come in as > web2py continues to evolve. > > On Nov 6, 5:00 pm, Mariano Reingart <reing...@gmail.com> wrote: > > > I don't think it's a good idea to add that to web2py core because: > > > * It introduces a new free-form table definition that we'll have to > > honor for backward compatibility forever > > * It breaks too much forward compatibility (forcing unknown version > > updates for new field "types" like wiki) > > * it could not be syntactically checked (a new problem to detect > > simple errors, like in views) > > * it will cause more troubles to static checkers or future > > autocomplete/calltip implementations > > * it will make even harder lazy table definition, migrations and fixtures > > * it adds more overhead to models > > * it doesn't get along with source control management tools, diff, > > pep-8 (80 char lines), etc. > > * its may be useful for simple tables, but what about you want to put > > an update function, complex default, widget or validator? > > * python zen: "There should be one-- and preferably only one --obvious > > way to do it." > > > For a wizard i think it may be useful because there is more freedom to > > change things, but here I don't find a good reason. > > Indeed, for wizard I would prefer more explicit dropdown fields, that > > would be more intuitive to begginers. > > > Best regards, > > > Mariano Reingarthttp://www.sistemasagiles.com.arhttp://reingart.blogspot.com > > > On Sat, Nov 6, 2010 at 1:56 AM, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > You could mix but not this way. > > > > db.define_table('person','name unique, address, married boolean, bio > > > wiki') > > > db.person.bio.default='...' > > > > On Nov 5, 10:04 pm, rochacbruno <rochacbr...@gmail.com> wrote: > > >> bio wiki will be a Markmin represent? > > > >> I think it is a good idea, but , if mixed with the normal sintax, will > > >> it work? > > > >> Some users, specially students, will try to mix for example: > > > >> > db.define_table('person','name unique, address, married boolean, bio > > >> > wiki',Field('foo','text'), format=' ' , migrate=' ' , compute= ' ' , > > >> > signature) > > > >> This could difficult the learning curve of DAL > > > >> Enviado via iPhone > > > >> Em 06/11/2010, às 00:53, mdipierro <mdipie...@cs.depaul.edu> escreveu: > > > >> > We could easily provide this alternative syntax: > > > >> > db.define_table('person','name unique, address, married boolean, bio > > >> > wiki') > > >> > form = SQLFORM.factory('name unique, address, married boolean, bio > > >> > wiki') > > > >> > by taking it out of the wizard and moving into the DAL (sql.py). Is it > > >> > a good idea?
