fixed some grammatical errors, some spelling mistakes, a bit of formatting, some code-highlighting, placeholder for testing section
parent
09319a5e19
commit
0a41588b95
1 changed files with 17 additions and 15 deletions
|
|
@ -3,18 +3,18 @@ This document is an attempt to describe the first step of a large project struct
|
|||
* SQLAlchemy
|
||||
* WTForms
|
||||
|
||||
Please feel free to fix and add you own tips.
|
||||
Please feel free to fix and add your own tips.
|
||||
|
||||
# Installation
|
||||
|
||||
## Flask
|
||||
|
||||
[Flask Installation](http://flask.pocoo.org/docs/installation/)
|
||||
I recommend using virtualenv: easy and allows multiple environments on the same machine and doesn't even require you to have super user rights on the machine (as the libs are localy installed).
|
||||
[Flask Installation](http://flask.pocoo.org/docs/installation/)<br/>
|
||||
I recommend using virtualenv: it is easy and allows multiple environments on the same machine and doesn't even require you to have super user rights on the machine (as the libs are locally installed).
|
||||
|
||||
## Flask-SQLAlchemy
|
||||
|
||||
SQLAlchemy provide an easy and advanced way to serialize your object to different type of relational database. In your virtualenv, install SQLAlchemy from pip:
|
||||
SQLAlchemy provides an easy and advanced way to serialize your object to different types of relational databases. In your virtualenv, install Flask-SQLAlchemy from pip:
|
||||
|
||||
pip install flask-sqlalchemy
|
||||
|
||||
|
|
@ -30,7 +30,7 @@ WTForms provides an easy way to handle user's data submission.
|
|||
|
||||
# Overview
|
||||
|
||||
Ok, so from now, we should have all the libs ready. Here the folder structures:
|
||||
Ok, so from now, we should have all the libs ready. Here are the folder structures:
|
||||
|
||||
/config.py
|
||||
/run.py
|
||||
|
|
@ -40,7 +40,7 @@ Ok, so from now, we should have all the libs ready. Here the folder structures:
|
|||
/app/constants.py
|
||||
/app/static/
|
||||
|
||||
For every module (or sub app... ) well have this file structure (here for the `users` module)
|
||||
For every module (or sub app... ) we'll have this file structure (here for the `users` module)
|
||||
|
||||
/app/users/__init__.py
|
||||
/app/users/views.py
|
||||
|
|
@ -63,7 +63,7 @@ You should serve your static files with a dedicated http server, but during the
|
|||
/app/static/css/reset.css
|
||||
/app/static/img/header.png
|
||||
|
||||
We'll create 4 modules, a user module (manage user's registration, login, lost password, profile edit and maybe third-party login/registration) an emails module intended to be used by a queuing server, and a posts and comments modules
|
||||
We'll create 4 modules, a user module (manage user's registration, login, lost password, profile edit and maybe third-party login/registration) an emails module intended to be used by a queuing server, and a posts and comments modules.
|
||||
|
||||
## Config
|
||||
|
||||
|
|
@ -114,10 +114,10 @@ We'll create 4 modules, a user module (manage user's registration, login, lost p
|
|||
```
|
||||
|
||||
* `_basedir` is a trick for you to get the folder where the script runs
|
||||
* `DEBUG` indicates that it is a dev environment, you'll get the very helpful error page from flask when an error occured.
|
||||
* `SECRET_KEY` will be use to sign the cookies. Change it and all your users will have to login again.
|
||||
* `DEBUG` indicates that it is a dev environment, you'll get the very helpful error page from flask when an error occurs.
|
||||
* `SECRET_KEY` will be used to sign cookies. Change it and all your users will have to login again.
|
||||
* `ADMINS` will be used if you need to email information to the site administrators.
|
||||
* `SQLALCHEMY_DATABASE_URI` and `DATABASE_CONNECT_OPTIONS` are SQLAlchemy connection options (hard to guess )
|
||||
* `SQLALCHEMY_DATABASE_URI` and `DATABASE_CONNECT_OPTIONS` are SQLAlchemy connection options (hard to guess)
|
||||
* `THREAD_PAGE` my understanding was 2/core... might be wrong :)
|
||||
* `CSRF_ENABLED` and `CSRF_SESSION_KEY` are protecting against form post fraud
|
||||
* `RECAPTCHA_*` WTForms comes with a `RecaptchaField` ready to use... just need to go to recaptcha website and get your public and private key.
|
||||
|
|
@ -183,11 +183,11 @@ and its constants in the `/app/users/constants.py` file:
|
|||
}
|
||||
```
|
||||
|
||||
First about the constants file, I like to have my constants in their own file and inside my module for 2 main reasons. Your constants will probably be used in your models, forms and views. The second reason is that it's a better organization for you to find them. Also, importing your constants as the module in uppercase indicate the constant type and the module name (like `USER` for `users.constants`) will avoid you name conflicts.
|
||||
First about the constants file, I like to have my constants in their own file and inside my module for 2 main reasons. Your constants will probably be used in your models, forms and views. The second reason is that it's a better organization for you to find them. Also, importing your constants as the module in uppercase indicates the constant type and the module name (like `USER` for `users.constants`) will avoid you name conflicts.
|
||||
|
||||
### First form
|
||||
|
||||
Now that we've done our object model, time to build the form that goes with it. We'll start with a registration and login form. The registration form will request the user's name, email and password. We'll use validators to ensure the user submitted correct values. Finally, a Recaptcha field (provided by flask) will avoid machine registration. Just in case you plan on having Term of Service, I added a BooleanField called accept_tos. Since this field is required, the user will have to check the checkbox generated by this field on the box. The login form will have only email and password with the same validators. Here's the `/app/users/forms.py` file:
|
||||
Now that we've done our object model, time to build the form that goes with it. We'll start with a registration and login form. The registration form will request the user's name, email and password. We'll use validators to ensure the user submitted correct values. Finally, a Recaptcha field (provided by flask) will avoid machine registration. Just in case you plan on having a Terms of Service, I added a `BooleanField` called accept_tos. Since this field is required, the user will have to check the checkbox generated by this field on the box. The login form will have only email and password with the same validators. Here's the `/app/users/forms.py` file:
|
||||
|
||||
```python
|
||||
from flask.ext.wtf import Form, TextField, PasswordField, BooleanField, RecaptchaField
|
||||
|
|
@ -209,13 +209,13 @@ Now that we've done our object model, time to build the form that goes with it.
|
|||
recaptcha = RecaptchaField()
|
||||
```
|
||||
|
||||
The first parameters for the field is the label we'll want to display for the field. For example the name field will be labelled as NickName on the form. For the password fields, another useful validator got used here, EqualTo, it compares the data contained in the current field with the data of the other specified field.
|
||||
The first parameter for the field is the label we'll want to display for it. For example the name field will be labelled as NickName on the form. For the password fields, another useful validator got used here, `EqualTo`, it compares the data contained in the current field with the data of the other specified field.
|
||||
|
||||
For more details of what can be done with WTForms check [here](http://wtforms.simplecodes.com/docs/dev/).
|
||||
|
||||
### First view
|
||||
|
||||
The view is where we'll declare our Blueprint. Using url_prefix will prefix every url you set using route. A nice feature from Flask-WTF is the `form.validate_on_submit` method: it check that the current request is a POST and that the form validates. Once the user is logged in we want to redirect the user to his profile (`/users/me/`). To prevent unauthenticated users to access this page, we'll create a decorator to protect it (`/app/users/decorators.py`):
|
||||
The view is where we'll declare our Blueprint. Using `url_prefix` will prefix every url you set using route. A nice feature from Flask-WTF is the `form.validate_on_submit` method: it checks that the current request is a POST and that the form validates. Once the user is logged in we want to redirect the user to his profile (`/users/me/`). To prevent unauthenticated users to access this page, we'll create a decorator to protect it (`/app/users/decorators.py`):
|
||||
|
||||
```python
|
||||
from functools import wraps
|
||||
|
|
@ -304,7 +304,7 @@ This decorator is checking that g.user has a value assigned to it, otherwise it
|
|||
|
||||
## First template
|
||||
|
||||
Jinja is integrated within Flask. One of the great feature of Jinja is the inheritance and the logic available (conditional structure, loop, context modification...). We'll create a `/app/templates/base.html` template from which we'll inherit from on each of our template. You can even have more than 1 inheritance (like having your template inheriting from `twocolumn.html` template which itself inherits from `main.html`). The base template is also a good place to display flash messages (`get_flashed_messages`), so every template will now display messages when needed.
|
||||
Jinja is integrated within Flask. One of the great features of Jinja is the inheritance and the logic available (conditional structure, loop, context modification...). We'll create a `/app/templates/base.html` template which we'll inherit from, on each of our templates. You can even have more than 1 inheritance (like having your template inheriting from `twocolumn.html` template which itself inherits from `main.html`). The base template is also a good place to display flash messages (`get_flashed_messages`), so every template will now display messages when needed.
|
||||
|
||||
```jinja
|
||||
<html>
|
||||
|
|
@ -432,6 +432,8 @@ Open your web-browser at [http://127.0.0.1:5000/users/me/], you should be redire
|
|||
|
||||
# Other good practices
|
||||
|
||||
# Testing
|
||||
|
||||
## Caching
|
||||
|
||||
## Javascript namespaces
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue