How decoupled are the Python frameworks?

[mdipierro]

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... at 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