look, this is for big project : Model Less Apps (using data models and modules in web2py)
http://www.web2pyslices.com/slice/show/1479/model-less-apps-using-data-models-and-modules-in-web2py <http://www.web2pyslices.com/slice/show/1479/model-less-apps-using-data-models-and-modules-in-web2py> <http://www.web2pyslices.com/slice/show/1479/model-less-apps-using-data-models-and-modules-in-web2py> El miércoles, 16 de enero de 2013 07:35:21 UTC-5, H.C. v. Stockhausen escribió: > > Hi, > > working with web2py is fun and I've learned a lot about web development > and Python. So 'yes', web2py is a great teaching tool and the docs are very > good too. Small projects are a breeze to realize and MVC separates the > concerns nicely. In larger projects however, I still manage to end up in a > bit of a mess. What I lack is a set of w2p design principles that go beyond > MVC. > > The type of questions I had are: > > - What should one never place into a Model, View, Controller, Module and > why? > - What should one always place into a Model, View, Controller, Module and > why? > - What known exceptions are there to these rules? > - Should a view ideally be assembled entirely from components? > - At what granularity should components, controllers and plugins operate? > - Should one try to create a (Rest) API first and then consume it oneself? > ... > > Here's how I would answer some of them today: > - Create a distinct controller for every business function (blog, shopping > cart, ...) > - Keep controller actions as small as possible. > - Move all utility functions into custom modules that don't depend on w2p > (i.e. they don't import gluon). > - Allow strictly no logic in views except for loops and branches. > - If DAL is too low-level or an alternative storage backend is used create > a ORM-type wrapper as a custom module. > - Assemble pages from components. > ... > > This is how I would go about my next w2p project today but I am sure that > I would have to learn some new lessons the hard way. > > How do you structure your apps to avoid spaghetti logic and to keep them > maintainable? I would also be interested to hear the kind of questions you > have? > > Maybe we can collect our lessons learned and compile a nice > document/catalogue. If there's already such a doc, please let me know. > > Best regards, > HC > > > > > > > > > > > --