Good:
- Works out of the box. Just download, open, choose password, press start. Your default browser starts automatically.
- Automatic updates (beta warning, bur works.)
- Built in editor and version control.
- Built in user registration and management.
- Automagic migrations (connecting to legacy databases are supported and documented, too)
- Built in support for multiple databases, including distributed transactions.
- Built in sqlite database, and postgres, mysql and even mssql seems to be just one config setting away.
- The whole official book is available online.
- Author intends to keep the api stable. (For anybody who has had the joy of supporting an application over multiple years and multiple versions of the same framework.)
- Bonus point 1: Nice default look and feel, and it is easily customizable. It's just html with placeholders.
- Bonus point 2: Applications built on top of web2py can be packed, downloaded and installed on another instance.
Needs improvement:
- The documentation. There is lots of official documentation, but the search engine is next to useless, and google picks up old, outdated blog post before the official documentation.
- Routing: From the official documetation: The url http://127.0.0.1:8000/examples/default/status/x/y/z?p=1&q=2 will presented to the controller as:
- request.args ['x', 'y', 'z']
- request.get_vars <Storage {'p': 1, 'q': 2}>
Why you'd like to separate between those are beyond my understanding. I always thought unifying those was one of the features of modern web frameworks.
Preliminary conclusion:
web2py is production ready and is already used a few public facing sites. To me it seems like a perfect match for small "intranet applications" but it is in no way limited to this.
Although I've not programmed apex myself, it often comes to mind because of features like online editing and redistributable applications built on top of it.
Q: "Why you'd like to separate between those are beyond my understanding. I always thought unifying those was one of the features of modern web frameworks."
ReplyDeleteA: From the online book
If the HTTP request is a GET, then request.env.request_method is set to "GET"; if it is a POST, request.env.request_method is set to "POST". URL query variables are stored in the request.vars Storage dictionary; they are also stored in request.get_vars (following a GET request) or request.post_vars (following a POST request).
Hi Bruno!
ReplyDeleteThanks for you comment. Do you know why it is done this way instead of the usual way?
This comment has been removed by the author.
ReplyDeleteThe way how it is done is easy to understand and very important in design.
ReplyDeleteargs = positional arguments in URL(without name)
vars = named arguments (key/value pairs)
Very important is distinction between GET and POST vars, so one can only allow POST vars in actions which modifie something e.g. in database.
And finally one have full controll over these parameters as they are separated!!
I really appreciate i18n approach in web2py. Simple, fast, easy maintanaible.
ReplyDeleteI had some sites running Pylons with pythonic i18n based on babel and I have already ripped off web2py "translation" component and replace babel in those sites ...
@David Marko: Sounds like a good explanation to me. It might just be that I'm reading everything through my rails/symfony glasses :)
ReplyDelete