Let me first comment on initial AchipA's proposal. Splitting models into different files targets same goals as my lazy_tables approach: it tries to speed up model load time by excluding the things that are _probably_ not needed in this browser request (read controller/function).
The differences are: * split models define static sets of tables. You think in advance what tables you will need, and you put just them into the model that will be executed for this controller Pros: same syntax everywhere Cons: many model files, in case of heavy optimisation - too many * lazy tables allow for more dynamic execution. If you know that you'll need some table always - you define it as usual. If you not sure - you define it as lazy. During runtime web2py automatically decides which one you need and finalizes their definitions. You get little time penalty for lazyness, but you save more a lot of init time for the tables you do not need. Pros: automatic decisions on which tables to init. Cons: syntax is different for 'lazy' and 'classic' tables, though converting b/w them is very simple (most of the work is one more intentation step). There is one more problem with split models approach though: they are too 'hard' and they try to predict the future. 1) You may know what tables you do need for this controller/function call but that does not neccesary stay fixed in the future. You will need to add more and more tables to 'this controller model' as application grows. 2) Opposite of (1) - if you stop using some tables in your controller due to refactoring you have to remember to delete them from model. With some programming approaches ('lazy' in traditional style) that includes 'deletion fears' - you have to do something despite it already works. 3) In rare cases even the same function of the same controller may need different tables depending on post data. For instance - I have a function that is named 'combo search' - it does the search either in one table or in another depending on what search button was clicked. Both tables are rather large, having more than 20 fields each. I'd very much like to avoid initialising unused table. I'd still vote for using lazy tables. Apart from somewhat awkward definition syntax they are quite flexible and do not have the drawbacks that I described. Awkwardness of syntax could be changed by coding lazyness into SQLTable.__init__ and SQLField.__init__ (and to validator init for completeness) but that will be quite intrusive patch. After all - if someone wants to take trouble of splitting models into separate files - then probably he can afford wrapping each table definition into function call instead. P.S. 'split models' and 'lazy tables' are compartible and could be used at once. But I do not really see a benefit in this - combining them will give very little speedup which will be further reduced by penalties of 'execution check'. Having lazy tables functionality w/o actually using lazy tables decreases perfomance a bit - btw - I didn't test for it. Can't right now - will have access to that hardware only on monday. Here is idea - we can have a 'class LazySQLDB(SQLDB)' (or I can have it directly in my model). All in all I see these approaches as interchangeable with a slight preference to lazy tables. On Friday 12 June 2009 01:52:29 mdipierro wrote: > What is we have folders like > > models/__init__.py > models/default/__init__.py > models/default/index.py > > and __init__ is executed for every action and controller > and default/__init__ is executed for every action in controller > default.py > and default/index only for the index action, etc etc. > > if there is no folder, then controllers are executed alphabetically > (but __init__ skips ahead if present). > > other depencies in models would result in a mess. > > What d you think? > > On Jun 11, 4:39 pm, AchipA <attila.cs...@gmail.com> wrote: > > On Jun 11, 10:08 pm, DenesL <denes1...@yahoo.ca> wrote: > > > Using the common code in the controller as a model substitute? > > > There goes the MVC separation. > > > And the other models still get executed. > > > > > > I think AchipA means execute one model only. > > > The problem is that models are executed before controllers (aren't > > > they?), but then this points back to using ifs in models as suggested > > > by Massimo. > > > > Not quite. I recommend we do the same as we do with views. E.g. if I'm > > in a stuff.py controller, then > > a) if there is no stuff.py in models, we include all models, > > convenient for development, friendly to newbies > > b) if there IS a stuff.py in models, we include ONLY that, and that > > model file is responsible for it's dependencies - see below. > > > > > Let's suppose we change that. > > > Where do you keep common model code? > > > common = used by all ctls, except those with a name > > > > Now, for the kicker - in the model we could do an equivalent of > > {{extend 'layout.html'}} (=sort of import ?) to include any > > dependencies. This would also pull in any 'common' models (just like > > we do with layout.html). Note the subtle difference - I don't want a > > single EXTRA model to be included - I want to avoid loading > > unnecessary models. -- Sincerely yours Alexey Nezhdanov --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@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 -~----------~----~----~----~------~----~------~--~---