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
-~----------~----~----~----~------~----~------~--~---
