Web2py - Noyau

Options de ligne de commande

Nous avons appris comment démarrer le serveur web2py à l'aide du widget GUI dans le chapitre précédent.

Ce widget peut être ignoré en démarrant le serveur à partir de command line rapide.

python web2py.py -a 'votre mot de passe' -i 127.0.0.1 -p 8000

Chaque fois que le serveur web2py démarre, il crée un fichier "parameters_8000.py"où tous les mots de passe sont stockés sous une forme hachée.

Pour des raisons de sécurité supplémentaires, la ligne de commande suivante peut être utilisée -

python web2py.py -a '<recycle>' -i 127.0.0.1 -p 8000

Pour le scénario ci-dessus, web2py réutilise les mots de passe hachés stockés dans "parameters_8000.py".

Au cas où, si le fichier "parameters_8000.py"est supprimé accidentellement ou pour d'autres raisons, l'interface d'administration Web est désactivée dans web2py.

Mappage / distribution d'URL

Le fonctionnement de web2py est basé sur model-view-controller, qui mappe l'URL sous une forme spécifique - http://127.0.0.1:8000/a/d/f.html

Il achemine jusqu'à la fonction “f()” mentionné dans le contrôleur d.pyest sous l'application nommée «a». Si le contrôleur n'est pas présent dans l'application, web2py utilise un contrôleur par défaut nommé“default.py”.

Si la fonction, telle que donnée dans l'URL n'est pas présente, la fonction par défaut appelée init()est utilisé. Le fonctionnement de l'URL est illustré schématiquement dans l'image ci-dessous.

L'extension .htmlest facultatif pour l'URL. L'extension détermine l'extension deViewqui rend la sortie de la fonction définie dans le contrôleur. Le même contenu est servi dans plusieurs formats à savoir html, xml, json, rss, etc.

La demande est transmise, basée sur les fonctions, qui acceptent les arguments et donnent la sortie appropriée à l'utilisateur. C'est le contrôleur, qui interagit avec le modèle et la vue de l'application pour donner la sortie selon les besoins de l'utilisateur.

web2py - Flux de travail

Le flux de travail de web2py est discuté ci-dessous -

Le serveur Web gère chaque requête HTTP simultanément dans son propre thread.
L'en-tête de la requête HTTP est analysé et transmis au répartiteur.
Le Dispatcher gère les demandes des applications et mappe les PATH_INFOdans l'URL de l'appel de fonction. Chaque appel de fonction est représenté dans l'URL.
Toutes les demandes de fichiers inclus dans le dossier statique sont gérées directement et les fichiers volumineux sont transmis au client.
Les demandes pour autre chose qu'un fichier statique sont mappées dans une action.
Si l'en-tête de la demande contient un cookie de session pour l'application, l'objet de session est récupéré; ou bien, un identifiant de session est créé.
Si l'action renvoie une valeur sous forme de chaîne, celle-ci est renvoyée au client.
Si l'action retourne un itérable, elle est utilisée pour boucler et diffuser les données vers le client.

Modèles conditionnels

Dans le chapitre précédent, nous avons vu la fonctionnalité du Controllers. web2py utilise des modèles, des vues et des contrôleurs dans chacune de ses applications. Par conséquent, il est également nécessaire de comprendre la fonctionnalité duModel.

Contrairement à toute autre application MVC, les modèles dans web2py sont traités comme conditionnels. Les modèles dans les sous-dossiers sont exécutés en fonction de l'utilisation de son contrôleur. Cela peut être démontré avec l'exemple suivant -

Considérez l'URL - http://127.0.0.1:8000/a/d/f.html

Dans ce cas, ‘a’ est le nom de l'application, ‘d’ est le nom du contrôleur et f()est la fonction associée au contrôleur. La liste des modèles qui seront exécutés est la suivante -

applications/a/models/*.py
applications/a/models/d/*.py
applications/a/models/d/f/*.py

Bibliothèques

web2py inclut des bibliothèques, qui sont exposées à toutes les applications en tant qu'objets. Ces objets sont définis dans les fichiers core sous le répertoire nommé «gluon».

De nombreux modules comme le modèle DAL n'ont pas de dépendances et peuvent être implémentés en dehors du cadre de web2py. Il maintient également les tests unitaires, ce qui est considéré comme une bonne pratique.

Applications

Les applications web2py sont présentées ci-dessous sous une forme schématique.

le Applications développés dans web2py sont composés des parties suivantes -

Models - Représente les tables de données et de base de données.
Controllers - Décrit la logique de l'application et le flux de travail.
Views - Aide à rendre l'affichage des données.
Languages - décrire comment traduire les chaînes de l'application dans diverses langues prises en charge.
Static files - Ne nécessite pas de traitement (par exemple, images, feuilles de style CSS, etc.).
ABOUT et README - Détails du projet.
Errors - Stocke les rapports d'erreur générés par l'application.
Sessions - Stocke les informations relatives à chaque utilisateur particulier.
Databases - stocker des bases de données SQLite et des informations de table supplémentaires.
Cache - Stockez les éléments d'application mis en cache.
Modules - Les modules sont d'autres modules Python facultatifs.
Private - Les fichiers inclus sont accessibles par les contrôleurs mais pas directement par le développeur.
Uploads - Les fichiers sont accessibles par les modèles mais pas directement par le développeur.

API

Dans web2py, models, controllers et views sont exécutés dans un environnement où certains objets sont importés pour les développeurs.

Global Objects - demande, réponse, session, cache.

Helpers- web2py inclut une classe d'assistance, qui peut être utilisée pour créer du HTML par programmation. Il correspond aux balises HTML, appelées“HTML helpers”.

Par exemple, A, B, FIELDSET, FORM, etc.

Session

Une session peut être définie comme un stockage d'informations côté serveur, qui est conservé tout au long de l'interaction de l'utilisateur dans toute l'application Web.

La session dans web2py est l'instance de la classe de stockage.

Par exemple, une variable peut être stockée dans la session comme

session.myvariable = "hello"

Cette valeur peut être récupérée comme

a = session.myvariable

La valeur de la variable peut être récupérée tant que le code est exécuté dans la même session par le même utilisateur.

L'une des méthodes importantes de web2py for session est “forget” -

session.forget(response);

Il indique à web2py de ne pas enregistrer la session.

Exécution de tâches en arrière-plan

Une requête HTTP arrive au serveur Web, qui gère chaque requête dans son propre thread, en parallèle. La tâche, qui est active, se déroule au premier plan tandis que les autres sont maintenues en arrière-plan. La gestion des tâches en arrière-plan est également l'une des principales fonctionnalités de web2py.

Les tâches chronophages sont de préférence conservées en arrière-plan. Certains des mécanismes sont répertoriés comme suit, qui gèrent les tâches d'arrière-plan -

CRON
Queues
Scheduler

CRON

Dans web2py, CRONdonne la possibilité d'exécuter la tâche dans les intervalles de temps spécifiés. Chaque application comprend un fichier CRON, qui définit ses fonctionnalités.

Planificateur

Le planificateur intégré aide à exécuter les tâches en arrière-plan en définissant la priorité. Il fournit un mécanisme de création, de planification et de modification des tâches.

Les événements programmés sont répertoriés dans les modèles avec le nom de fichier “scheduler.py”.

Créer une application

Nous avons eu un aperçu de la création de modèles et de contrôleurs dans web2py. Ici, nous nous concentrerons sur la création de l'application nommée“Contacts”. L'application doit conserver une liste d'entreprises et une liste de personnes qui travaillent dans ces entreprises.

Création de modèle

Ici, l'identification des tables pour le dictionnaire de données est le modèle. Le modèle de l'application Contacts sera créé sous le "models" Dossiers. Le fichier est stocké dansmodels/db_contacts.py.

# in file: models/db_custom.py
db.define_table('company', Field('name', notnull = True, unique = True), format = '%(name)s')
db.define_table(
   'contact',
   Field('name', notnull = True),
   Field('company', 'reference company'),
   Field('picture', 'upload'),
   Field('email', requires = IS_EMAIL()),
   Field('phone_number', requires = IS_MATCH('[\d\-\(\) ]+')),
   Field('address'),
   format = '%(name)s'
)

db.define_table(
   'log',
   Field('body', 'text', notnull = True),
   Field('posted_on', 'datetime'),
   Field('contact', 'reference contact')
)

Une fois le fichier ci-dessus créé, les tableaux sont accessibles à l'aide de l'URL http://127.0.0.1:8000/contacts/appadmin

Création du contrôleur

le Controller comprendra certaines fonctions pour répertorier, modifier et supprimer les contacts.

# in file: controllers/default.py
def index():return locals()
def companies():companies = db(db.company).select(orderby = db.company.name)
return locals()

def contacts():company = db.company(request.args(0)) or redirect(URL('companies'))
contacts = db(db.contact.company == company.id).select(orderby = db.contact.name)
return locals()

@auth.requires_login()
def company_create():form = crud.create(db.company, next = 'companies')
return locals()

@auth.requires_login()
def company_edit():company = db.company(request.args(0)) or redirect(URL('companies'))
form = crud.update(db.company, company, next='companies')
return locals()

@auth.requires_login()
def contact_create():db.contact.company.default = request.args(0)
form = crud.create(db.contact, next = 'companies')
return locals()

@auth.requires_login()
def contact_edit():contact = db.contact(request.args(0)) or redirect(URL('companies'))
form = crud.update(db.contact, contact, next = 'companies')
return locals()

def user():return dict(form = auth())

La création du view ainsi que sa sortie seront discutés dans le chapitre suivant.