Request for some formal guidelines on models in modules

123 views
Skip to first unread message

Johann Spies

unread,
Feb 27, 2012, 3:18:43 AM2/27/12
to web...@googlegroups.com

The thread in this mailing list with the subject "model less apps (a blog example)"  and some other remarks about using model-less applications for better speed and memory usage is the background of this email.

I would be glad if the guidelines (not necessarily recipes) on this can become part of the official Web2py documentation. 

I am working on a long term app which currently have 93 tables in the database.  The database will develop into a multilevel database with many more tables and in the end probably several millions or records.

I have started to migrate some of the less used tables to modules and it is working in the normal app, but I have problems with appadmin as I have described in the thread I refer to in the first paragraph.  Even in Bruno's blog example using appadmin produces tickets.

This is because web2py was not originally designed for this type of setup.

So my request is:

If the way to go for large databases (many tables) is to move the table definitions to modules, please make it  part of the Web2py design, adapt appadmin to handle it and provide official documentation about it.

Regards
Johann
--
Because experiencing your loyal love is better than life itself,
my lips will praise you.  (Psalm 63:3)

Bruno Rocha

unread,
Feb 27, 2012, 3:49:21 AM2/27/12
to web...@googlegroups.com

Massimo and Mariano are developing a conditional model_map, so you will be able to choose which model files to run for each requested controller, it will be a very good add to web2py.

Maybe it will be included only in web2py 2.0.

I still think we need a model-less approach using modules, and it needs to be documented, but appadmin was not designed to wotk with that, so it is better to have it as a plugin (a new appadmin)

Even with the new model map I will still use the modules approach because it has some advantages, it looks more like Python, it works well with my code editor auto conplete and linter without hacks, and it is more reusable in terms of Object Oriented programming. BTW I am not using appadmin for database. I am replacing it with a simple plugin called badmin.

wait web2py 2.0 to see the new model mapping feature.

http://zerp.ly/rochacbruno

Johann Spies

unread,
Feb 27, 2012, 3:57:22 AM2/27/12
to web...@googlegroups.com
On 27 February 2012 10:49, Bruno Rocha <rocha...@gmail.com> wrote:

Massimo and Mariano are developing a conditional model_map, so you will be able to choose which model files to run for each requested controller, it will be a very good add to web2py.

Maybe it will be included only in web2py 2.0.



Good news!  Thanks.

Johann

pbreit

unread,
Feb 27, 2012, 3:31:45 PM2/27/12
to web...@googlegroups.com
I feel like if I'm going to try and learn model-less app development, it's time to re-evaluate other frameworks.

Bruno Rocha

unread,
Feb 27, 2012, 4:14:09 PM2/27/12
to web...@googlegroups.com


On Mon, Feb 27, 2012 at 5:31 PM, pbreit <pbreit...@gmail.com> wrote:
I feel like if I'm going to try and learn model-less app development, it's time to re-evaluate other frameworks.

I do not agree, web2py has a lot of features, executed "models" and global scope are not the only good feature of web2py, we can have a very great experience with all the web2py API even working with other frameworks. i.e: I am using DAL with Tkinter and there are people using template engine with bottle and wxhtml.

Being self contained, having no need for configurations and the easy of deployment + the best DAL, the best template engine, very great documentation and a lot of helpers have better value than the executed models approach.

If you think the only good thing in web2py is the "models" approach, I think its time to re-evaluate web2py to see all the other good features it has.

There are nothing strange or hard-to-learn in model less approach, it is only object oriented programming and pure Python, I think experienced web2py developers have to know Python O.O at some stage.

O.O, modules, Classes, Methods, Inheritance, Instances, Namespaces etc.. what is strange on this programming approach?

IMO: if you think that the use of modules is difficulty, it is time to re-evaluate Python as a language.

BTW, It is always the time to evaluate other frameworks, you do not have to rely in only one tool, web2py is great and for me is the best! but Pyramid is also great, Django is great and Flask, Bottle etc.. all good frameworks, It is very nice to give a try to everyone of them!

--

Anthony

unread,
Feb 27, 2012, 5:25:22 PM2/27/12
to web...@googlegroups.com
Also, keep in mind that "model-less" can mean many things. It doesn't necessarily entail the highly class-based approach you see in Bruno's Movuca. It could mean simply moving some standard table definitions from model files into functions in modules. In fact, I think Bruno's class-based design and the notion of "model-less" are largely orthogonal -- you can define classes in model files, and you can use a non-classed-based approach in modules.

Anthony

Johann Spies

unread,
Feb 28, 2012, 2:05:44 AM2/28/12
to web...@googlegroups.com
On 28 February 2012 00:25, Anthony <abas...@gmail.com> wrote:
Also, keep in mind that "model-less" can mean many things. It doesn't necessarily entail the highly class-based approach you see in Bruno's Movuca. It could mean simply moving some standard table definitions from model files into functions in modules. In fact, I think Bruno's class-based design and the notion of "model-less" are largely orthogonal -- you can define classes in model files, and you can use a non-classed-based approach in modules.

I do not particularly like the OO-approach in programming and would prefer to use classes only when it is clearly the best (or easiest) option.

Here is a very simple example of defining a table in a module without using classes explicitly:

In the model (db.py):

from gluon import current
current.db = db

In the module(tabelle.py):

from gluon import *
import re

def tabel1():
    db = current.db
    db.define_table('toets',
                    Field('veld1'),
                    Field('veld2')
                    )

    print db.tables
    return db

Controller:
from  applications.toets.modules.tabelle import *
def index():
     db = tabel1()
    print "in controller"
    print db.tables
    vorm = crud.create(db.toets)
    return dict(vorm = vorm)


And in appadmin.py do the same import as above and


def get_databases(request):
    db = tabel1()
    dbs = {}
...
:
Reply all
Reply to author
Forward
0 new messages