Hi Gergo, Thank you very much for your email. Your prospective as a Django user is very valuable here.
On Jan 1, 9:48 am, pihentagy <[email protected]> wrote: > Hi all! > > After some django experience I tried to learn web2py. My impressions > and issues: > > I cannot understand why you should write: > Field('customer', db.partner, requires=IS_IN_DB(db, > 'partner.id','partner.id')) > > and not just simply > Field('customer') The sytnax is Field(name, type). The default type is a string. If you want it to be a reference it has to said explicitly. You do the same in Django. The validator is optional and, in fact, since 1.74 you get that validator by default if web2py knows how to represent a partner. For example db.define_table('partner',Field('name'),format='%(names)s') db.define_table('whatever',Field('partner',db.partner)) db.whatever.partner.requires is set by default to IS_IN_DB (db,'partner.id','%(name)s') > and on the other hand how a validator defines the appearance of a db > form? Not seems to be good design... > > Also the api doc of IS_IN_DB isn't much > helpful:http://www.web2py.com/examples/static/epydoc/web2py.gluon.validators.... > > Generally, the documentation seems not so complete, as in django. > > ps: if I find errors in comparing django and web2py, where should I > report it? You can email it here so we can discuss it. > I dig up some info for IS_IN_SET, it accepts dicts, but it is not > mentioned on the > site:http://www.web2py.com/examples/static/epydoc/web2py.gluon.validators....http://www.web2py.com/examples/global/vars/IS_IN_SET > > Using an autoincrement integer called id in every db is a good > practice, but it is impossible to follow legacy databases. > For definition of a legacy database: > Suppose you have some system with existing database, and you should > create a web-based interface for that. > So, you cannot alter the tables in the legacy database (not > considering oracle, where AFAIK you should insert a sequence number > manually, so an alter table is not sufficient). > > So, for this case it should be good to have arbitrary (and also multi- > field) PK support. We actually support this for some databases but not all. You can find some info here: http://groups.google.com/group/web2py/browse_thread/thread/2b877c0b79c1af40 We are in the process of re-factoring the DAL so that it will remain backward compatible and this issue will eventually be addressed for all databases. > thanks > Gergo -- 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.
