Not sure what you mean by FK (the editor?) reference. We will be doing some table inheritance for auditing, as far as adding comments I would probably just go with the comments plugin ; ). Fancier stuff could be handled with a special "containers" or "layouts". I suppose we might have to "break" the guidelines or change them at some point in time, in the meantime they help us identify patterns that get repeated a lot as well which will be very useful (hopefully) when it comes to optimization.
We are focused on making what we call Universal Cake. In a nutshell this translates into software that is highly accessible to as many as possible users and programmers. So in contrast to some folks at Wired Magazine who think Craigs List needs a major makeover, we find it's user interface to be highly accessible and therefore useful to a very large audience. We would probably give them bonus points for limiting change in fact. Perhaps web2py would make it even more cool on the inside though ;). Table Inheritance... Following example I have not tested, it was wacked from http://www.web2pyslices.com/main/slices/take_slice/35 comments http://web2py.com/book/default/section/6/14?search=Table+Inheritance Table I want to include in another table #audit field group audit=db.Table(None,'audit', Field('unique_id', default=uuid.uuid4(), writable=False, readable=False), Field('active', 'boolean', default=True, comment='set Active off to delete record'), Field('created_by', db.auth_user, default=user_id, writable=False), Field('created_on', 'datetime', default=request.now, writable=False), Field('modified_by', db.auth_user, default=user_id, update=user_id, writable=False), Field('modified_on', 'datetime', default=request.now, update=request.now, writable=False), Field('reason', requires=IS_IN_SET(('change', 'new info', 'correction'))) ) My other table db.define_table('home', Field('city'), audit, ) On Mar 1, 2:59 pm, Thadeus Burgess <[email protected]> wrote: > What if the db definitions of "news" requires the db definitions in > "polls" (such as a news post including a poll, the FK references would > not be there ?) > > In this case, would you always use "reference <tablename>" instead of > "db.<tablename>" for FK relationships? > > -ThadeusOn Mon, Mar 1, 2010 at 1:54 PM, Christopher Steel > <[email protected]> wrote: > > Hi Guido, > > > I use a method some where between yours and Thadeus's solution. The > > thing I find interesting about having some settings in their own files > > is that is allows you to isolate "features" and to have different > > developers work on different features without stomping on one > > another's work all the time. This makes troubleshooting, rewrites, > > integration / merging much smoother as well. When a feature is "ready" > > you can drop it in. This has some pretty interesting potential for > > automated installations as well... > > > So if I was working on a "News" section for a site I might have the > > following files to work on while whomever is doing the "Polls" section > > of the site would have a similar set of files to work on but referring > > to polls rather than news. > > > models/a_init_news.py > > models/news.py > > models/z_process_news.py > > > controllers/news.py > > > views/news/index.html > > views/news/add.html > > ... > > > static/news.css # not really required > > > Works for us. > > > Cheers, > > > Chris > > > On Feb 28, 9:56 am, Thadeus Burgess <[email protected]> wrote: > >> I do > > >> A_settings.py # global settings and flags > >> B_w2p.py # web2py related things, auth/crud/service declarations > >> C_modelA.py > >> D_modelB.py #relies on model a so it executes after > > >> -Thadeus > > >> On Sun, Feb 28, 2010 at 5:19 AM, Guido Kollerie <[email protected]> wrote: > >> > I'd like to have one file with configurable settings instead of having > >> > these settings spread out over mulitple models and controllers. What's > >> > the best practise for this? > > >> > My solution is to create a '_settings.py' model. I prepended it with an > >> > underscore to ensure it is the first excuted model file. This way the > >> > settings in it can be used by other model files, most notable db.py. > >> > This works under OS X, though I am not sure if this is a cross platform > >> > safe way to ensure _settings.py is actually loaded first. > > >> > Reason for not simply including all settings in db.py is that I do > >> > want to check in db.py in my DVCS, but not the settings such as DB > >> > password, password of the SMTP user, and other potentially sensitive > >> > information. > > >> > Thoughts? > > >> > -- > >> > Guido Kollerie > > >> > -- > >> > 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. > > > -- > > 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 > > athttp://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 [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.
