you might want to look up some of the materials presented as arguments under: "design by responsibility", and David Parnas original writings on cohesion and coupling (i.e. his 1972 paper) -- I think Wikipedia entry on him gives a fairly good, generic overview w/ links. For design by responsibility, look up Rebecca Wirfs-Brock, and CRC.
- Yarko On May 5, 2:18 pm, cjrh <[email protected]> wrote: > On May 4, 1:26 pm, canna <[email protected]> wrote: > > > so how would you share functions between controllers easily? without > > passing global objects to the functions all the time? > > Functions in a module should really only have access to identifiers > and namespaces within that module; hence passing "db" as an argument. > However, if, inside the function, assumptions are made about the > existence or validity of specific tables and fields, then it is > probably better that the function be declared in the same place as > "db", which would be in the model file. If possible, perhaps the > best alternative is to write the module in such a way that no > specifics about the db are needed, and then the function can be > imported into the model file. This is sometimes possible, for > instance, your function inside the module could take another function > as an argument, and in the model file, you import and use the model > function by passing your db-specific function in. > > FWIW the fact that web2py controllers have access to a pre-initialized > namespace for things like "db", "session" and so on is something of an > exception, and indeed supporters of other python frameworks sometimes > paint that in a negative light. I think it the web2py way is a net > positive (due to convenience), but different people weight things > differently. The global object instances in web2py models and > controllers should really be considered as a specific, intentional, > useful exception to the rule, not a recommended way of doing things in > the general case.
