Interesting post. I would like to make some comments about design decisions that went into web2py:
- For each app Model/View/Controllers/Language Files/Static Files/ Modules/Cron Tasks are stored in separated folders - You can code only the models (no controllers and no view) and you get a fully functional admin interface - You can develop only controllers (with or without models but no views) and you get a fully working application with workflow - There is a convention for dispatching. You can override it with routes. - There is no metadata in the framework. URLs are mapped into an app (within the web2py instance), into a controller file, and into a function (action) in that controller file. - You can have multiple apps within a web2py instance (they can be installed, uninstalled, packaged, compiled without restarting web2py) - You can have multiple model files, multiple controllers and multiple views. You can override the mapping between controllers and default views. - You can group files (models/controllers/views/static files) functionally into plugins. Plugins can be packaged separately from the app and applied to multiple apps. - Plugins expose components (i.e. reusable objects that can be embedded in a page and talk to their own controllers via ajax). - Plugin components are coded as any other web2py models/controller/ view but the form submission is automatically trapped (transparently to the user) and executed via ajax so that, if the component contains a form only the component is reloaded upon submissions of the form. - web2py supports FORM, SQLFORM, SQLFORM.factory and CRUD for automtical generation of forms (from a model or other structure). All web2py forms execute postbacks and modify themselves to report error messages. A form is comprised of widgets that contain validators. There is a default layout but it can be customized in the view by allocating widgets or individual html tags. - You can put doctests in actions and we provide a web interface for testing the app online. - It completely abstracts the database backend (we support 10 different database backends including Google App Engine) thus make the code very portable. - It authomatically writes sql for queries, for create table and alter table. -Web2py provides a Role Based Access Control mechanism with plugguble login components so that you can authenticate using multiple mechanism including Gmail and Twitter for example. Specifically about you concerns:- better scalability - easy to test => web2py is very easy to test because of the web based interface to doctests - easy to maintain => In web2py "Do not repeat yourself" trumps "explicit if better than implicit". This means code is very compact. - easy to re-use code for different applications => using plugins - easy to migrate/port => because of DAL Massimo On Dec 7, 4:38 pm, shocks <benmari...@googlemail.com> wrote: > Hi > > I'm getting back into Python after a long break. I've been developing > large enterprise apps solely with Adobe Flex (ActionScript) for the > past couple years. During that time I've used a number of 'MVC' > frameworks to glue the bits together - among them Cairngorm, a > modified implementation of Cairngorm using the Presentation Model > pattern, PureMVC, Mate (an IOC container but with an MVC > implementation) and Parsley (IOC but you have to roll-you-own MVC). > During that time I've been in large teams (30 Flex + 30 Java) to small > teams (2 Flex + 1 Java). The motivation of these frameworks is the > decouple your concerns, allowing your apps to be more scalable, easier > to test, and supposedly easier to maintain. Some do the decoupling > better job than others, but there is also the question of "how > decoupled is your code from the framework"? It's all well and good > having something clever working behind the scenes wiring and routing > everything together, but I wonder where this leaves the code base if > the framework, which was selected at the beginning of the project, is > replaced with something else months or years later (i.e. the framework > just doesn't scale as expected, the community involvement dies and > it's no longer maintained properly, etc). I've seen it happen and > I've been experienced the pain of detangling massive amounts of code > which is full of framework specific imports, methods and boilerplate > code. And then there's updating the unit tests! > > My question is how good are the current crop of Python frameworks? > I've used Django twice in production and didn't like that much. The > implementation is Django specific for starters. I've picked up Pylons > and I'm trying that out. I'm not sure how well it fares? I do feel a > bit uneasy about the code generation that some of the Python > frameworks do. Pylons creates something like 20 files for a > 'helloworld'. It does do some great things out of the box, but I > wonder where that leaves your own code. After spending 3-6 months on > your Pylons webapp, how easy is it to move to something else? Maybe > one of the Python IOC once they mature. What are some good techniques > people are using to future (framework) proof their apps? > > I'm interested to hear people experiences with the various frameworks > and how decoupled their code is from them. The best of the current > Flex frameworks for me is Parsley. The only noticeable Parlsey code > is an '[Inject]' meta tag here and there and a couple import > statements. All the complicated object creation and messaging is done > higher up the chain. > > Cheers, > Ben -- http://mail.python.org/mailman/listinfo/python-list
