I agree with this. It comes to using the right tool for the job. Web2py is just a tool, and an excellent one if your working with one application. Other systems are better designed for multiple apps, and if thats what you need then you should use them for the job.
Web2py is great for large sites/applications, look at sahanapy. -- Thadeus On Sat, May 15, 2010 at 10:15 AM, mdipierro <mdipie...@cs.depaul.edu> wrote: > The current design is motivated by two principles: > 1) each app should be able to be packed and moved independently > 2) if multiple apps access the same db, at least one of the should be > clearly in charge of migrations > 3) even if two apps access the same db table(s) it is not obvious they > need to see the same model (i.e. all fields in the same order). > > > > On May 15, 5:51 am, Thadeus Burgess <thade...@thadeusb.com> wrote: >> Yes, web2py runs fine with 50 models. And this is awesome if your just >> dealing with one application.... >> >> What gets messy is when you have two applications, which depend on >> each others models. >> >> You end up having to stick the common models in a module, and >> importing it, but now you have three places to edit model files, and >> this is where django shines in its re-usable app structure.. >> >> In web2py you have to do >> >> from common_model import myModel >> >> in both applications, its complex and stupid. In django its just >> >> from myapp1 import myModel >> >> And you start using it, everything is still defined in myapp1, no need >> for redefining your models or even sticking them in a third location. >> >> -- >> Thadeus >> >> On Fri, May 14, 2010 at 4:13 PM, howesc <how...@umich.edu> wrote: >> > i have a variety of applications running on web2py. www.tenthrow.com >> > has 33 tables in one postgres schema, and another 9 in another >> > schema. it runs happily along with the low traffic we get right now. >> > all my tables of the same schema are in the same model file (maybe >> > it's time to split it out). and i use the web2py access controls to >> > limit what users get to see the admin backend (at least i hope i have >> > it right!) >> >> > christian >> >> > On May 13, 8:44 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: >> >> I assume those tables are not all referencing each other but they can >> >> be group based on their function and the groups can be organized in a >> >> tree where the children may refer a table in the parent group. I would >> >> create a module for each group of tables and have a function in the >> >> module that takes db and creates the table. In the development phase I >> >> would import all modules in one model file in the proper order. If >> >> this is slow, in production, move the imports into the controllers (or >> >> the actions) that need the tables. >> >> >> It may also be a good idea to do most of the settings >> >> db.table.field.attribute=whatever in the actions that generates the >> >> forms as opposed to the models. >> >> >> Anyway 30 tables should not be a problem but make sure migrate=False >> >> for speed and bytecde compiled the app. >> >> >> Massimo >> >> >> > On Thu, May 13, 2010 at 23:07, Thadeus Burgess <thade...@thadeusb.com> >> >> > wrote: >> >> > > But the problem with web2py is that what if you don't want portal >> >> > > models to execute when they are on the public portion of the site? But >> >> > > the public depends on the portals models and visa versa. No matter >> >> > > which way you hash it, your going to have a massive web2py spaghetti >> >> > > on your plate with some giant meatballs. =) >> >> >> > > If your not a stickler for perfection and don't mind everything being >> >> > > pulled in regardless of where they are in your site, you should be >> >> > > fine. >> >> >> > > Currently, it is not an appropriate solution to even put the models in >> >> > > an external file that can be imported by each app, as the way web2py >> >> > > works your not supposed to "import" your models... yes you can make a >> >> > > function and pass your db object, but like I said, plate of spaghetti. >> >> >> > What we can do (developers) to solve this problem? >> >> >> > > -- >> >> > > Thadeus >> >> >> > > On Thu, May 13, 2010 at 7:54 PM, Alexandre Andrade >> >> > > <alexandrema...@gmail.com> wrote: >> >> > >> to build large app, you can: >> >> >> > >> 1. split you tables over several models, like >> >> > >> db.py >> >> > >> db_000_user_management.py >> >> > >> db_001_portal.py >> >> > >> db_002_ecommerce.py >> >> >> > >> and so on. >> >> >> > >> 2. split your code and html over several controllers: >> >> >> > >> default.py >> >> > >> portal.py >> >> > >> shop.py >> >> >> > >> views/default/*.html >> >> > >> views/portal/*.html >> >> > >> views/shop/*.html >> >> >> > >> and so on. >> >> >> > >> -- >> >> > >> Atenciosamente >> >> >> > >> -- >> >> > >> ========================= >> >> > >> Alexandre Andrade >> >> > >> Hipercenter.com >> >> >> > >> 2010/5/13 thedangler <matt...@gmail.com> >> >> >> > >>> I'm confused when to make apps. I'll be making a pretty decent size >> >> > >>> website and it has over 30 tables. The site will have different >> >> > >>> functionalities and for the most part i have only seen code for apps >> >> > >>> that do two or one thing. >> >> >> > >>> So do i make multiple apps. If so how do i know when to make a new >> >> > >>> one. If not is there a proper way to build large applications. >> >> >> > >>> Thank you. >> >> >> > -- >> >> > Álvaro Justen - Turicas >> >> > http://blog.justen.eng.br/ >> >> > 21 9898-0141 >
