From b2de3bc8a26e4af6bca966e44a8101e3b4242dd0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Villoz=20S=C3=A9bastien?= Date: Tue, 26 May 2020 08:25:58 +0200 Subject: [PATCH 1/3] =?UTF-8?q?Add=20"Supprimer=20le=20mod=C3=A8le=20"menu?= =?UTF-8?q?.py"=20in=20the=20chapter=203,=20create=20an=20images=20blog.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- sources/38-web2py-french-translation-in-progress/03.markmin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sources/38-web2py-french-translation-in-progress/03.markmin b/sources/38-web2py-french-translation-in-progress/03.markmin index b28e298e..b0d355b4 100644 --- a/sources/38-web2py-french-translation-in-progress/03.markmin +++ b/sources/38-web2py-french-translation-in-progress/03.markmin @@ -451,7 +451,7 @@ Comme avant, depuis la page **site** dans **admin**, créez une nouvelle applica [[image @///image/en1900.png center 480px]] Nous commençons par créer un modèle, une représentation des données persistente dans l'application (les images à uploader, leurs noms, et les commentaires). Premièrement, vous avez besoin de créer/éditer un fichier modèle que nous appellerons, par manque d'imagination, "db.py". Nous supposons que le code suivant remplacera tout code existant dans "db.py". Les modèles et contrôleurs doivent avoir une extension ``.py`` puisque c'est du code Python. Si l'extension n'est pas précisée, elle est ajoutée par web2py. Les vues, elles, ont une extension ``.html`` puisqu'elles contiennent principalement du code HTML. - +Supprimer le modèle "menu.py". Modifiez le fichier "db.py" en cliquant sur le bouton "modifier" correspondant : [[image @///image/en2000.png center 480px]] From eb579375404e695fdc78757bd7eff4424256e424 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Villoz=20S=C3=A9bastien?= Date: Tue, 26 May 2020 09:23:49 +0200 Subject: [PATCH 2/3] Chapter 3 - French : Translation update/corrections --- .../03.markmin | 102 +++++++++--------- 1 file changed, 51 insertions(+), 51 deletions(-) diff --git a/sources/38-web2py-french-translation-in-progress/03.markmin b/sources/38-web2py-french-translation-in-progress/03.markmin index b0d355b4..cc1ede8f 100644 --- a/sources/38-web2py-french-translation-in-progress/03.markmin +++ b/sources/38-web2py-french-translation-in-progress/03.markmin @@ -58,7 +58,7 @@ En cliquant sur "interface d'administration" vous arriverez sur la page d'identi Le mot de passe administrateur est le mot de passe que vous avez choisi au démarrage. Notez bien qu'il n'y a qu'un seul administrateur, et de ce fait, un seul mot de passe administrateur. Pour des raisons de sécurité, le développeur se verra demander un nouveau mot de passe à chaque redémarrage de web2py à moins que l'option ne soit spécifiée. C'est un mécanisme distinct des authentifications des applications web2py. -Après que l'administrator soit logué sur web2py, le navigateur est redirigé à la page "site". +Après que l'administrateur soit logué sur web2py, le navigateur est redirigé à la page "site". [[image @///image/en700.png center 480px]] @@ -67,7 +67,7 @@ web2py est fourni avec trois applications : ``admin``:inxx ``examples``:inxx ``welcome``:inxx ``scaffolding``:inxx - Une application **admin**, celle que vous utilisez maintenant. - Une application **examples**, avec une documentation en ligne interactive et une copie du site officiel web2py. -- Une application **welcome**. C'est le modèle basique pour toute autre application web2py. This is the basic template for any other web2py application. Elle est désignée comme ''application échafaudage''. C'est également l'application qui accueille un utilisateur au démarrage. +- Une application **welcome**. C'est le modèle basique pour toute autre application web2py. Elle est désignée comme ''application échafaudage''. C'est également l'application qui accueille un utilisateur au démarrage. ``appliances``:inxx Les applications prêtes à l'emploi sont désignées comme ''appliances'' web2py. Vous pouvez télécharger un grand nombre d'appliances disponibles librement depuis ``appliances``:cite . Les utilisateurs web2py sont bien entendu encouragés à soumettre leurs propres appliances, que ce soit sous forme open-source ou non (compilées et packagées). @@ -82,7 +82,7 @@ Depuis la page ''site'' de l'application **admin**, vous pouvez exécuter les op - **éditer** une application. ----- -Lorsque vous créez une nouvelle application en utilisant **admin**, elle démarre en effectuant un clone de l'application de référence "welcome" avec un "models/db.py" qui créé une base de données SQLite, s'y connecte, instancie Auth, Crud, Service, et les configure. Elle fournit également un "controller/default.py" qui propose les actions "index", "download", "user" pour la gestion des utilisateurs, et "call" pour les services. Par la suite, nous supposons que ces fichiers ont été supprimés; nous créérons les applications sans base. +Lorsque vous créez une nouvelle application en utilisant **admin**, elle démarre en effectuant un clone de l'application de référence "welcome" avec un "models/db.py" qui créé une base de données SQLite, s'y connecte, instancie Auth, Crud, Service, et les configure. Elle fournit également un "controller/default.py" qui propose les actions "index", "download", "user" pour la gestion des utilisateurs, et "call" pour les services. Par la suite, nous supposons que ces fichiers ont été supprimés; nous créerons les applications sans base. ----- web2py propose également un **assistant**, décrit plus tard dans ce chapitre, qui peut écrire un code de référence alternatif pour vous en se basant sur les layouts et les plugins disponibles sur le web et sur la description haut niveau des modèles. @@ -98,7 +98,7 @@ Vous pouvez créer une nouvelle application simplement en tapant son nom dans le [[image @///image/en800.png center 447px]] -Après avoir appuyé sur [create], l'application est créée comme copie de l'application pré-construite "welcome". +Après avoir appuyé sur [create], l'application est créée comme copie de l'application préconstruite "welcome". [[image @///image/en900.png center 480px]] @@ -114,7 +114,7 @@ Pour éditer une application, cliquez sur le bouton ''modifier'' pour la nouvell La page **modifier** vous dit ce que contient l'application. Toute application web2py possède un ensemble de fichiers, dont la plupart tombe dans l'une de ces six catégories : - **modèles**: décrit la représentation des données. -- **controleurs**: décrit la logique de l'application et le workflow. +- **contrôleurs**: décrit la logique de l'application et le workflow. - **vues**: décrit la présentation des données. - **langues**: décrit comment traduire l'application dans d'autres langues. - **modules**: les modules Python qui appartiennent à l'application. @@ -148,7 +148,7 @@ Lorsque vous visitez l'URL http://127.0.0.1:8000/myapp/default/index ``:code -l'action index du contrôleur par défaut de l'application myapp est appelée. Elle rnvoie une chaîne de caractères que le navigateur affiche pour nous. Votre page devrait ressembler à cela : +L'action index du contrôleur par défaut de l'application myapp est appelée. Elle renvoie une chaîne de caractères que le navigateur affiche pour nous. Votre page devrait ressembler à cela : [[image @///image/en1100.png center 480px]] @@ -193,7 +193,7 @@ Vous pouvez également spécifier une vue avec ``response.view = 'default/someth Vous pourrez en savoir plus sur ce sujet au chapitre 10. -Si vous retournez à "modifier" et que vous cliquez sur index, vous nerrez maintenant la page HTML suivante : +Si vous retournez à "modifier" et que vous cliquez sur index, vous verrez maintenant la page HTML suivante : [[image @///image/en1200.png center 480px]] @@ -206,7 +206,7 @@ Pour des raisons de déboguage vous pouvez insérer {{=response.toolbar()}} ``:code -au code dans une vue et et cela vous affichera les informations utiles, incluant la requête, la réponse et les objets de session, et la liste de toutes les requêtes à la base de données avec leur timing. +au code dans une vue et cela vous affichera les informations utiles, incluant la requête, la réponse et les objets de session, et la liste de toutes les requêtes à la base de données avec leur timing. #### C'est parti pour compter ``session``:inxx @@ -406,9 +406,9 @@ Pensez bien qu'en général ce n'est pas une bonne idée de passer des données #### Internationalisation -Votre code est susceptible d'inclure des chaînes de caractères codées en dur telles que "Quel est votre nom ?". Vous devriez être capable de personnaliser ces chaînes sans éditer le code et en particlulier insérer des traductions pour ces chaînes dans différents langages. De ce fait, si un visiteur a ses préférences de langue du navigateur définies à "Italien", web2py utilisera la traduction italienne pour les chaînes de caractères, si possible. Cette fonctinonalité de web2py est appelée "internationalisation" et est décrite plus précisément dans le chapitre suivant. +Votre code est susceptible d'inclure des chaînes de caractères codées en dur telles que "Quel est votre nom ?". Vous devriez être capable de personnaliser ces chaînes sans éditer le code et en particulier insérer des traductions pour ces chaînes dans différents langages. De ce fait, si un visiteur a ses préférences de langue du navigateur définies à "Italien", web2py utilisera la traduction italienne pour les chaînes de caractères, si possible. Cette fonctionnalité de web2py est appelée "internationalisation" et est décrite plus précisément dans le chapitre suivant. -Nous observons juste ici que si vous souhaitez utiliser cette fonctionnalité vous devrez marquer les chaînes qui nécessitent une traduction. Ceci est fait grâce aux guillements dans le code tel que +Nous observons juste ici que si vous souhaitez utiliser cette fonctionnalité vous devrez marquer les chaînes qui nécessitent une traduction. Ceci est fait grâce aux guillemets dans le code tel que `` "What is your name?" @@ -450,7 +450,7 @@ Comme avant, depuis la page **site** dans **admin**, créez une nouvelle applica [[image @///image/en1900.png center 480px]] -Nous commençons par créer un modèle, une représentation des données persistente dans l'application (les images à uploader, leurs noms, et les commentaires). Premièrement, vous avez besoin de créer/éditer un fichier modèle que nous appellerons, par manque d'imagination, "db.py". Nous supposons que le code suivant remplacera tout code existant dans "db.py". Les modèles et contrôleurs doivent avoir une extension ``.py`` puisque c'est du code Python. Si l'extension n'est pas précisée, elle est ajoutée par web2py. Les vues, elles, ont une extension ``.html`` puisqu'elles contiennent principalement du code HTML. +Nous commençons par créer un modèle, une représentation des données persistantes dans l'application (les images à uploader, leurs noms, et les commentaires). Premièrement, vous avez besoin de créer/éditer un fichier modèle que nous appellerons, par manque d'imagination, "db.py". Nous supposons que le code suivant remplacera tout code existant dans "db.py". Les modèles et contrôleurs doivent avoir une extension ``.py`` puisque c'est du code Python. Si l'extension n'est pas précisée, elle est ajoutée par web2py. Les vues, elles, ont une extension ``.html`` puisqu'elles contiennent principalement du code HTML. Supprimer le modèle "menu.py". Modifiez le fichier "db.py" en cliquant sur le bouton "modifier" correspondant : @@ -486,7 +486,7 @@ Analysons ceci ligne par ligne. La ligne 1 définit une variable globale appelée ``db`` qui représente la connexion à la base de données. Dans ce cas, c'est une connexion à une base SQLite qui est stockée dans le fichier "applications/images/databases/storage.sqlite". Lorsque l'on utilise SQLite, si le fichier de base de données n'existe pas, il est créé. Vous pouvez changer le nom de ce fichier aussi bien que le nom de la variable globale ``db``, mais il est pratique de leur donner le même nom pour s'en souvenir plus facilement. -Les lignes 3 à 6 définissent uen table "image". ``define_table`` est une méthode de l'objet ``db``. Le premier argument, "image", est le nom de la table que nous définissons. Les autres arguments sont les champs appartenant à cette table. Cette table a un champ appelé "title", un champ appelé "file", et un dernier appelé "id" qui sert de clé primaire ("id" n'est pas déclaré explicitement car les tables ont un champ id par défaut). Le champ "title" est une chaîne, et le champ "file" est de type "upload". "upload" est un type spécial de champ utilisé par la couche d'abstraction à la base de données web2py (DAL) pour stocker les noms des fichiers uploadés. web2py sait comment uploader des fichiers (via streaming s'ils sont gros), les renommer proprement, et les stocker. +Les lignes 3 à 6 définissent une table "image". ``define_table`` est une méthode de l'objet ``db``. Le premier argument, "image", est le nom de la table que nous définissons. Les autres arguments sont les champs appartenant à cette table. Cette table a un champ appelé "title", un champ appelé "file", et un dernier appelé "id" qui sert de clé primaire ("id" n'est pas déclaré explicitement car les tables ont un champ id par défaut). Le champ "title" est une chaîne, et le champ "file" est de type "upload". "upload" est un type spécial de champ utilisé par la couche d'abstraction à la base de données web2py (DAL) pour stocker les noms des fichiers uploadés. web2py sait comment uploader des fichiers (via streaming s'ils sont gros), les renommer proprement, et les stocker. Lorsqu'une table est définie, web2py effectue l'une de ces actions possibles : - si la table n'existe pas, la table est créée; @@ -504,11 +504,11 @@ format=lambda row: row.title Les lignes 8 à 12 définissent une autre table appelée "post". Un post a un "author", un "email" (nous souhaitons stocker l'adresse mail de l'auteur du post), un "body" de type "texte" (nous souhaitons l'utiliser pour stocker le commentaire actuel posté par l'auteur), et un champ "image_id" de type référence qui pointe sur ``db.image`` via le champ "id". -A la ligne 14, ``db.image.title`` représente le champ "title" de la table "image". L'attribut ``requires`` vous autorise à définir les pré-requis/contrainte qui seront pris en charge par les formulaires web2py. L'unicité de "title" est requise ici : +A la ligne 14, ``db.image.title`` représente le champ "title" de la table "image". L'attribut ``requires`` vous autorise à définir les prérequis/contrainte qui seront pris en charge par les formulaires web2py. L'unicité de "title" est requise ici : ``IS_NOT_IN_DB(db, db.image.title)``:code -''Notez que ceci est optionel car il est automatiquement défini par ``Field('title', unique=True)``''. +''Notez que ceci est optionnel car il est automatiquement défini par ``Field('title', unique=True)``''. Les objets représentant ces contraintes sont appelés validateurs. Plusieurs validateurs peuvent être groupés dans une liste. Les validateurs sont exécutés dans l'ordre où ils apparaissent. ``IS_NOT_IN_DB(a, b)`` est un validateur spécial qui vérifie que la valeur du champ ``b`` pour un nouvel enregistrement n'est pas déjà dans ``a``. @@ -602,9 +602,9 @@ def index(): return dict(images=images) ``:code -Cette action renvoie un dictionnaire. Les clés des objets du dictionnaire sont interprétés commme variables passées à la vue associée à l'action. Lors du développement, s'il n'y a pas de vue, l'action est rendue par la vue "generic.html" qui est fournie avec toute application web2py. +Cette action renvoie un dictionnaire. Les clés des objets du dictionnaire sont interprétés comme variables passées à la vue associée à l'action. Lors du développement, s'il n'y a pas de vue, l'action est rendue par la vue "generic.html" qui est fournie avec toute application web2py. -L'action index effectue une sélection de tous les champs (``db.image.ALL``) depuis la table image, ordonnée par ``db.image.title``. Le résultat de la sélection est un objet ``Rows`` contenant les enregistrements. Assignez le à une variable locale appelée ``images`` renvoyée par l'action à la vue. ``images`` est itérable et ses éléments sont des lignes sélectionnées. Pour chaque ligne, les colonnes peuvent être accédées comme dictionnaires : +L'action index effectue une sélection de tous les champs (``db.image.ALL``) depuis la table image, ordonnée par ``db.image.title``. Le résultat de la sélection est un objet ``Rows`` contenant les enregistrements. Assignez-le à une variable locale appelée ``images`` renvoyée par l'action à la vue. ``images`` est itérable et ses éléments sont des lignes sélectionnées. Pour chaque ligne, les colonnes peuvent être accédées comme dictionnaires : ``images[0]['title']`` ou l'équivalent à ``images[0].title``. Si vous n'écrivez pas une vue, le dictionnaire est rendu par "views/generic.html" et un appel à l'action index ressemblerait à : @@ -755,9 +755,9 @@ Voici comment tout apparaîtra pour un visiteur. Lorsqu'un visiteur soumet un commentaire via cette page, le commentaire est stocké dans la base de données et ajouté à la fin de la page. -#### Ajout de l'authetification +#### Ajout de l'authentification -L'API web2py pour les contrôles d'acces basés sur le rôle (Role-Based Access Control) est assez sophistiquée, mais pour l'instant nous nous limiterons à une restriction d'accès à l'action show pour les utilisateurs authentifiés, en se reportant à une discussion plus détaillée en chapitre 9. +L'API web2py pour les contrôles d'accès basés sur le rôle (Role-Based Access Control) est assez sophistiquée, mais pour l'instant nous nous limiterons à une restriction d'accès à l'action show pour les utilisateurs authentifiés, en se reportant à une discussion plus détaillée en chapitre 9. Pour limiter l'accès aux utilisateurs authentifiés, nous avons besoin de compléter trois étapes. Dans un modèle, par exemple "db.py", nous avons besoin d'ajouter : `` @@ -864,11 +864,11 @@ response.menu = [ [ 'Index', False, URL('index') ] ] ### Un wiki simple ``wiki``:inxx ``RSS``:inxx ``Ajax``:inxx ``XMLRPC``:inxx -Dans cette section, nous allons construire un simple wiki de rien en utilisant uniquement les APIs bas niveau (à l'opposé de l'utilisation des possibilités pré-construites de web2py démontrées dans la section suivante). Le visiteur sera capable de créer des pages, les chercher (par titre) et de les éditer. Le visiteur sera également capable de poster des commentaires (exactement comme dans les applications précédentes), et également de poster des documents (en pièces jointes aux pages) et les lier depuis les pages. Comme convention, nous adoptons la syntaxe Markmin pour la syntaxe de notre wiki. Nous allons également implémenter une page de recherche avec Ajax, un flux RSS pour les pages, et un gestionnaire pour chercher les pages via XML-RPC``xmlrpx``:cite . Le diagramme suivant liste les actions que nous avons besoin d'implémenter et les liens que nous avons l'intention de construire entre eux. +Dans cette section, nous allons construire un simple wiki de rien en utilisant uniquement les APIs bas niveau (à l'opposé de l'utilisation des possibilités préconstruites de web2py démontrées dans la section suivante). Le visiteur sera capable de créer des pages, les chercher (par titre) et de les éditer. Le visiteur sera également capable de poster des commentaires (exactement comme dans les applications précédentes), et également de poster des documents (en pièces jointes aux pages) et les lier depuis les pages. Comme convention, nous adoptons la syntaxe Markmin pour la syntaxe de notre wiki. Nous allons également implémenter une page de recherche avec Ajax, un flux RSS pour les pages, et un gestionnaire pour chercher les pages via XML-RPC``xmlrpx``:cite . Le diagramme suivant liste les actions que nous avons besoin d'implémenter et les liens que nous avons l'intention de construire entre eux. [[yUML diagram @///image/en3400.png center 200px]] -Commençons par créer un nouvelle application de base, que nous nommons "mywiki". +Commençons par créer une nouvelle application de base, que nous nommons "mywiki". Le modèle doit contenir trois tables : page, comment et document. Aussi bien comment que document référence page puisqu'ils lui appartiennent. Un document contient un champ fichier de type upload comme dans l'application précédente pour l'image. @@ -926,7 +926,7 @@ Editez le contrôleur "default.py" et créez les actions suivantes : - documents: gère les documents attachés à une page - download: télécharge un document (comme dans l'exemple des images) - search: affiche une boite de recherche et, via un callback Ajax, renvoie tous les titres correspondant à la requête utilisateur -- callback: la fonction callback Ajax. Elle renvoir l'HTML qui va être embarqué dans la page de recherche lorsque le visiteur tape. +- callback: la fonction callback Ajax. Elle renvoie l'HTML qui va être embarqué dans la page de recherche lorsque le visiteur tape. Voici le contrôleur "default.py" : `` @@ -1226,19 +1226,19 @@ maintenant cette représentation est internationalisée et vous pouvez utiliser %m/%d/%Y %H:%M:%S `` -Pensez bien que par défaut l'Anglais n'est pas traduit puisque web2py support que les application sont écrites en anglais. Si vous souhaitez que l'internationalisation fonctionne pour l'anglais, vous avez besoin de créer le fichier de traduction (en utilisant admin) et vous avez besoin de déclarer que la langue courante de l'application est autre que l'anglais, par exemple : +Pensez bien que par défaut l'Anglais n'est pas traduit puisque web2py support que les applications sont écrites en anglais. Si vous souhaitez que l'internationalisation fonctionne pour l'anglais, vous avez besoin de créer le fichier de traduction (en utilisant admin) et vous avez besoin de déclarer que la langue courante de l'application est autre que l'anglais, par exemple : `` T.current_languages = ['null'] `` -### Le wiki web2py pré-construit +### Le wiki web2py préconstruit -Vous pouvez maintenant oublier le code que nous avons construit dans la section précédente (pas ce que vous avez appris à propos des APIs web2py, mais juste le code spécifique à l'exemple) puisque nous allons travailler sur un exemple de wiki pré-construit avec web2py. +Vous pouvez maintenant oublier le code que nous avons construit dans la section précédente (pas ce que vous avez appris à propos des APIs web2py, mais juste le code spécifique à l'exemple) puisque nous allons travailler sur un exemple de wiki préconstruit avec web2py. En fait, web2py propose des possibilités incluant l'attachement de media, tags, tag cloud, les permissions de page, et le support pour oembed ``oembed``:cite et les composants (chapitre 14). Ce wiki peut être utilisé avec n'importe quelle application web2py. ------ -Notez que l'API du wiki pré-construit est encore considérée comme expérimentale et de légers changements sont encore possibles. +Notez que l'API du wiki préconstruit est encore considérée comme expérimentale et de légers changements sont encore possibles. ------ Nous supposons ici que nous démarrons de zéro depuis un simple clone de l'application "welcome" appelée "wikidemo". Modifiez le contrôleur et remplacez l'action "index" avec : @@ -1247,7 +1247,7 @@ Nous supposons ici que nous démarrons de zéro depuis un simple clone de l'appl def index(): return auth.wiki() ``:code -C'est fait ! Vous avez un wiki totalement fonctionnel. A ce point, aucune page n'a été créée et afin de créer des pages vous devez vous connecter et être membre du groupe appelé "wiki_editor" ou "wiki_author". Si vous êtes connecté en tant qu'administrateur, le group "wiki_editor" est créé automatiquement et vous en êtes membre. La différente entre les éditeurs et les auteurs est que les éditeurs peuvent créer les pages, les éditer et en supprimer, alors que les auteurs peuvent créer les pages (avec certaines restrictions optionnelles) et peuvent seulement éditer/supprimer les pages qu'ils ont créées. +C'est fait ! Vous avez un wiki totalement fonctionnel. A ce point, aucune page n'a été créée et afin de créer des pages vous devez vous connecter et être membre du groupe appelé "wiki_editor" ou "wiki_author". Si vous êtes connecté en tant qu'administrateur, le groupe "wiki_editor" est créé automatiquement et vous en êtes membre. La différente entre les éditeurs et les auteurs est que les éditeurs peuvent créer les pages, les éditer et en supprimer, alors que les auteurs peuvent créer les pages (avec certaines restrictions optionnelles) et peuvent seulement éditer/supprimer les pages qu'ils ont créées. La fonction ``auth.wiki()`` renvoie un dictionnaire avec une clé ``content`` qui est interprétée par la vue par défaut "views/default/index.html". Vous pouvez faire votre propre vue pour cette action : @@ -1309,7 +1309,7 @@ La méthode ``wiki`` a quelques paramètres additionnels qui seront expliqués p #### Les bases de MARKMIN -La syntaxe MARKMIN vous autorise à marquer du texte en **gras** en utilisant ``**gras**``, du texte ''italic'' avec ``''italic''``, et du ``code`` en le délimitant par des doubles quotes inverses. Les titres doivent être préfixés par un #, les sections par ##, et les sous-sections par ###. Utilisez un moins(-) pour préfixer un object non ordonné et plus(+) pour un objet ordonné dans une liste. Les URLs sont automatiquement converties en liens. Voici un exemple de texte markmin : +La syntaxe MARKMIN vous autorise à marquer du texte en **gras** en utilisant ``**gras**``, du texte ''italique'' avec ``''italic''``, et du ``code`` en le délimitant par des doubles quotes inverses. Les titres doivent être préfixés par un #, les sections par ##, et les sous-sections par ###. Utilisez un moins(-) pour préfixer un objet non ordonné et plus(+) pour un objet ordonné dans une liste. Les URLs sont automatiquement converties en liens. Voici un exemple de texte markmin : `` # This is a title @@ -1440,7 +1440,7 @@ Si vous créez une page avec pour slug "wiki-menu" elle sera interprétée comme - - Contact us > \@////contactus `` -Chaque ligne est un object du menu. Nous avons utilisé le double tiret pour les éléments imbriqués. Le symbole ``>`` sépare le titre de l'objet du menu de son lien. +Chaque ligne est un objet du menu. Nous avons utilisé le double tiret pour les éléments imbriqués. Le symbole ``>`` sépare le titre de l'objet du menu de son lien. Pensez bien que le menu est ajouté à ``response.menu``. Il ne le remplace pas. Le menu ``[wiki]`` avec les fonctions de service est automatiquement ajouté. @@ -1474,7 +1474,7 @@ ou le tag cloud : #### Etendre les possibilités de auth.wiki -Si votre application wiki prête à l'emploi devient plus compliquée, peut être souhaiteriez-vous personnaliser les enregistrement de la base du wiki par l'interface Auth ou exposer les formulaires personnalisés pour les tâches de wiki CRUD. Par exemple, vous pourriez vouloir personnaliser la représentation d'un enregistrement de la table wiki ou ajouter un nouveau champ de validation. Ce n'est pas autorisé par défaut, puisque le modèle du wiki est défini uniquement après que la méthode auth.wiki() ait requêté l'interface du wiki. Pour autoriser l'accès à la configuration spécifique de la base du wiki à travers le modèle de votre application, vous devez ajouter la phrase suivante dans votre fichier de modèle (i.e. db.py) +Si votre application wiki prête à l'emploi devient plus compliquée, peut être souhaiteriez-vous personnaliser les enregistrements de la base du wiki par l'interface Auth ou exposer les formulaires personnalisés pour les tâches de wiki CRUD. Par exemple, vous pourriez vouloir personnaliser la représentation d'un enregistrement de la table wiki ou ajouter un nouveau champ de validation. Ce n'est pas autorisé par défaut, puisque le modèle du wiki est défini uniquement après que la méthode auth.wiki() ait requêté l'interface du wiki. Pour autoriser l'accès à la configuration spécifique de la base du wiki à travers le modèle de votre application, vous devez ajouter la phrase suivante dans votre fichier de modèle (i.e. db.py) `` # Make sure this is called after the auth instance is created @@ -1536,20 +1536,20 @@ Les comopsants comme celui ci-dessus peuvent être embarqués dans les pages wik Ceci indique simplement que nous voulons inclure l'action "manage_things" définie dans le contrôleur "default" comme "composant" Ajax. --------- -La plupart des utilisateur pourront construire des applications relativement complètes en utilisant simplement ``auth.wiki`` pour créer des pages, des menus et des composants personnalisables embarqués dans les pages du wiki. Les wikis peuvent être pensés comme un mécanisme autorisant les membres d'un groupe à créer des pages, mais peuvent également être pensés comme un moyen de développer des application de manière modulaire. +La plupart des utilisateur pourront construire des applications relativement complètes en utilisant simplement ``auth.wiki`` pour créer des pages, des menus et des composants personnalisables embarqués dans les pages du wiki. Les wikis peuvent être pensés comme un mécanisme autorisant les membres d'un groupe à créer des pages, mais peuvent également être pensés comme un moyen de développer des applications de manière modulaire. --------- ### Plus sur **admin** ``admin``:inxx -L'interface d'administration fournir des fonctionnalités additionnelles que nous allons rapidement voir ici. +L'interface d'administration fournie des fonctionnalités additionnelles que nous allons rapidement voir ici. #### Site ``site``:inxx Cette page est l'interface principale d'administration de web2py. Elle liste toutes les applications installées sur la gauche, alors qu'il y a certaines actions spéciales possibles via des formulaires sur la droite. -La première d'entre elles montre la version de web2py et propose la mise à jour si des nouvelles versions sont disponibles. Bien sur, vérifiez que vous ayez une sauvegarde fonctionnelle avant d'effectuer une mise à jour ! +La première d'entre elles montre la version de web2py et propose la mise à jour si des nouvelles versions sont disponibles. Bien sûr, vérifiez que vous ayez une sauvegarde fonctionnelle avant d'effectuer une mise à jour ! Il y a ensuite deux autres formulaires qui permettent la création de nouvelles applications (simple ou en utilisant un assistant de création en ligne) en spécifiant leur nom. ``Instant Press``:inxx ``Movuca``:inxx @@ -1599,9 +1599,9 @@ Pour chaque application installée, vous pouvez utiliser la page ''site'' pour : - Se rendre à la page ''erreurs'' (voir ci-après). - Nettoyer les fichiers temporaires (sessions, erreurs, et fichiers cache.disk). - Tout packager. Ceci retourne un fichier tar contenant une copie complète de l'application. Nous suggérons que vous fassiez un nettoyage des fichiers temporaires avant de la packager. -- Compiler l'application. S'il n'y a pas d'erreur, cette option va compiler en bytecode tous les modèles, les contrôleurus et les vues. Etant donné que les vues peuvent étendre et inclure d'autres vues dans un arbre, avant d'effectuer la compilation en bytecode, l'arbre de vue pour tout contrôleur est replié en un seul fichier. L'effet marquant est qu'une application compilée en bytecode est plus rapide, puisqu'il n'y a pas de parsing de templates ou de substitutions de chaînes qui puissent survenir à l'exécution. +- Compiler l'application. S'il n'y a pas d'erreur, cette option va compiler en bytecode tous les modèles, les contrôleurs et les vues. Etant donné que les vues peuvent étendre et inclure d'autres vues dans un arbre, avant d'effectuer la compilation en bytecode, l'arbre de vue pour tout contrôleur est replié en un seul fichier. L'effet marquant est qu'une application compilée en bytecode est plus rapide, puisqu'il n'y a pas de parsing de templates ou de substitutions de chaînes qui puissent survenir à l'exécution. - Paquet compilé. Cette option est seulement présente pour les application compilées. Elle permet de packager l'application sans code source pour la distribution sans code source. Notez que Python (comme de nombreux autres langages de programmation) peut techniquement être décompilé ; donc la compilation ne fournit pas une protection complète du code source. Néanmoins, la décompilation peut être difficile et illégale. -- Retirer compilé. Ceci supprime tout simplement le bytecode compilé des modèles, vues et contrôleurs de l'application. Si l'application a été packagée avec le code source ou éditée localement, il n'y a aucun souci à supprimer les fichier compilés, et l'application continuera à fonctionner. Si l'application a été installée depuis un fichier compilé et packagé, alors il n'y a aucune sécurité, car il n'y a pas de code source pour revenir , et l'application ne fonctionnera plus. +- Retirer compilé. Ceci supprime tout simplement le bytecode compilé des modèles, vues et contrôleurs de l'application. Si l'application a été packagée avec le code source ou éditée localement, il n'y a aucun souci à supprimer les fichiers compilés. L'application continuera à fonctionner. Si l'application a été installée depuis un fichier compilé et packagé alors il n'y a aucune sécurité car il n'y a pas de code source pour revenir et l'application ne fonctionnera plus. ``admin.py``:inxx @@ -1609,7 +1609,7 @@ Pour chaque application installée, vous pouvez utiliser la page ''site'' pour : Toutes les fonctionnalités disponibles depuis la page d'administration du site sont également accessibles en programmation via l'API définie dans le module ``gluon/admin.py``. Ouvrez simplement un shell Python et importez ce module. ------- -Si un SDK Google App Engine est installé dans la page d'administration ''site'', la page montre un bouton pour pousser vos application vers GAE. Si ``python-git`` est installé, il y a également un bouton pour pousser l'application vers Open Shift. Pour installer des application sur ``Heroku`` ou tout autre système d'hébergement, vous devrez regarder dans le répertoire "scripts" pour le script associé. +Si un SDK Google App Engine est installé dans la page d'administration ''site'', la page montre un bouton pour pousser vos applications vers GAE. Si ``python-git`` est installé, il y a également un bouton pour pousser l'application vers Open Shift. Pour installer des applications sur ``Heroku`` ou tout autre système d'hébergement, vous devrez regarder dans le répertoire "scripts" pour le script associé. #### A propos ``about``:inxx ``license``:inxx @@ -1622,11 +1622,11 @@ Vous pouvez utiliser la syntaxe ``MARKMIN``, ou ``gluon.contrib.markdown.WIKI`` #### Design ``EDIT``:inxx -Vous avez déjà utilisé la page ''modifier'' dans ce chapitre. Nous allons ici voir quelques fonctionnalités complémentaire sur la page ''modifier''. +Vous avez déjà utilisé la page ''modifier'' dans ce chapitre. Nous allons ici voir quelques fonctionnalités complémentaires sur la page ''modifier''. - Si vous cliquez sur n'importe quel nom de fichier, vous pouvez voir les contenus avec la syntaxe surlignée (fonction du code). - Si vous cliquez sur modifier, vous pouvez éditer le fichier via une interface web. - Si vous cliquez sur supprimer, vous pouvez supprimer le fichier (définitivement). -- Si vous cliquez sur tester, web2py effectuera les tests. Les tests sont écrits par le développeur en utilisant les doctests PYthon, et chaque fonction devrait avoir ses propres tests. +- Si vous cliquez sur tester, web2py effectuera les tests. Les tests sont écrits par le développeur en utilisant les doctests Python, et chaque fonction devrait avoir ses propres tests. - Vous pouvez ajouter des fichiers de langue, scanner l'application pour découvrir toutes les chaînes, et éditer les traductions via l'interface web. - Si les fichiers statiques sont organisés en dossiers et sous-dossiers, l'affichage de la hiérarchie de dossier peut être alternée en cliquant sur le nom du dossier. @@ -1648,7 +1648,7 @@ L'image ci-dessous montre comment éditer un fichier de langue, dans ce cas, le L'administration web2py inclut un débogueur web. ``debugger``:inxx -En utilisant l'éditeur web fourni, vous pouvez ajouter des points d'arrêt au code Python et, depuis la console de débogage associée, vous pouvez inspecter les variables systèmes à ces points d'arrêts et relancer l'exécution. Ceci est illustré dans les captures d'acran suivantes : +En utilisant l'éditeur web fourni, vous pouvez ajouter des points d'arrêt au code Python et, depuis la console de débogage associée, vous pouvez inspecter les variables systèmes à ces points d'arrêts et relancer l'exécution. Ceci est illustré dans les captures d'écran suivantes : La console interactive sert également de bloc-notes python. [[image @///image/debugger.png center 480px]] @@ -1678,12 +1678,12 @@ Les IDEs ont généralement leur propre débogueur inter-process, e.g. PyCharm o #### Le Shell Python web -Si vous cliquez sur le lien "shell" en dessous de l'ongler des contrôleurs dans ''modifier'', web2py ouvrira un shell Python web et exécutera les modèles pour l'application courante. Ceci vous permet de parler de manière interactive avec votre application. +Si vous cliquez sur le lien "shell" en dessous de l'onglet des contrôleurs dans ''modifier'', web2py ouvrira un shell Python web et exécutera les modèles pour l'application courante. Ceci vous permet de parler de manière interactive avec votre application. [[image @///image/en4700.png center 480px]] ------- -Faites attention en utilisant le shell web - car différentes requêtes shell peuvent être exécutées dans différents threads. Ceci peut facilement mener à des erreurs, notamment si vous jouez sur la création et les connexions aux bases de données. Pour ce type d'activités (i.e. si vous avez besoin de persistence), il est mieux d'utiliser la ligne de commande python. +Faites attention en utilisant le shell web - car différentes requêtes shell peuvent être exécutées dans différents threads. Ceci peut facilement mener à des erreurs, notamment si vous jouez sur la création et les connexions aux bases de données. Pour ce type d'activités (i.e. si vous avez besoin de persistance), il est mieux d'utiliser la ligne de commande python. ------- #### Crontab @@ -1713,7 +1713,7 @@ Seuls les administrateurs peuvent accéder au ticket : Le ticket montre la trace (traceback), et le contenu du fichier qui a causé le problème, et l'état complet du système (variables, requête, session, etc...). Si l'erreur survient dans une vue, web2py montre la vue convertie depuis l'HTML en code python. Ceci permet de facilement identifier la structure logique du fichier. -Par défaut, les tickets sont stockés sur le système de fichiers et regroupés par trace. L'interface d'administration fournit des vues agrégées (type de trace et le nombre d'occurence) et une vue détaillée (tous les tickets sont listés par id de ticket). L'administrateur peut basculer entre les deux vues. +Par défaut, les tickets sont stockés sur le système de fichiers et regroupés par trace. L'interface d'administration fournit des vues agrégées (type de trace et le nombre d'occurrence) et une vue détaillée (tous les tickets sont listés par id de ticket). L'administrateur peut basculer entre les deux vues. Notez que **admin** montre partout le code syntaxiquement surligné (par exemple, dans les rapports d'erreur, les mots-clés web2py sont montrés en orange). Si vous cliquez sur un mot-clé web2py, vous êtes redirigé à une page de documentation à propos du mot-clé. @@ -1734,7 +1734,7 @@ vous obtenez le ticket suivant : [[image @///image/en5000.png center 480px]] -Notez que web2py a converti la vue depuis l'HTML en fichier Python, et l'erreur décrite dans le ticket se referre au code Python généré et non au fichier de vue original : +Notez que web2py a converti la vue depuis l'HTML en fichier Python, et l'erreur décrite dans le ticket se refère au code Python généré et non au fichier de vue original : [[image @///image/en5100.png center 480px]] @@ -1771,9 +1771,9 @@ Vous pouvez en lire plus sur Mercurial ici : http://mercurial.selenic.com/ `` -#### Integration GIT +#### Intégration de GIT ``git``:inxx -L'application admin inclut également l'intégration git. Les librairies git Python sont requises : +L'application admin inclut également l'intégration de git. Les librairies git Python sont requises : `` pip install gitpython ``:code @@ -1781,7 +1781,7 @@ pip install gitpython et ensuite, par application, vous devez cloner ou configurer un dépôt git. Après ces étapes, le menu de gestion pour chaque application gérée par git montrera les actions push/pull de git. -Les application qui ne sont pas gérées par git sont ignorées. +Les applications qui ne sont pas gérées par git sont ignorées. Vous pouvez effectuer des actions pull/push depuis le dépôt distant par défaut. @@ -1796,7 +1796,7 @@ Le wizard va vous guider à travers les différentes étapes nécessaires pour l - Choisissez un nom pour l'application - Configurez l'application et choisissez les plugins requis -- Construisez les modèles requis (ceci crééra les pages CRUD pour chaque modèle) +- Construisez les modèles requis (ceci créera les pages CRUD pour chaque modèle) - Vous permettre d'éditer les vues de ces pages en utilisant la syntaxe MARKMIN L'image ci-dessous montre la seconde étape du process. @@ -1809,7 +1809,7 @@ Les autres étapes sont plutôt assez explicites. Le wizard fonctionne bien pour ce qu'il doit mais est considéré comme une ''fonctionnalité expérimentale'' pour deux raisons : -- Les application créées avec le wizard et éditées manuellement, ne peuvent pas être modifiées plus tard par le wizard. +- Les applications créées avec le wizard et éditées manuellement, ne peuvent pas être modifiées plus tard par le wizard. - L'interface du wizard va changer dans le temps en incluant le support de plus de fonctionnalités et un développement visuel aisé. Quel que soit le cas, le wizard est un outil clé en main pour le prototypage rapide et peut être utilisé pour amorcer une nouvelle application avec un layout alternatif et des plugins optionnels. @@ -1827,7 +1827,7 @@ Le fichier "0.py" est plus ou moins auto-documenté, peu importe, voici la plupa `` GAE_APPCFG = os.path.abspath(os.path.join('/usr/local/bin/appcfg.py')) `` -Ceci devrait pointer vers le fichier "appcfg.py" fourni avec le SDK Google App Engine. Si vous avez le SDK, vous pouvez vouloir change ces paramètres de configuration à la bonne valeur. Ceci vous permettra de déployer vers GAE depuis l'interface d'administration. +Ceci devrait pointer vers le fichier "appcfg.py" fourni avec le SDK Google App Engine. Si vous avez le SDK, vous pouvez vouloir changer ces paramètres de configuration à la bonne valeur. Ceci vous permettra de déployer vers GAE depuis l'interface d'administration. ``DEMO_MODE``:inxx @@ -1865,11 +1865,11 @@ Notez que l'application admin inclut le plugin "plugin_jqmobile" qui contient jQ Le contrôleur **appadmin** est relativement petit et facile à lire ; il fournit un exemple pour définir une interface de base de données. -**appadmin** montre quelles bases de données sont disponibles et quelles tables existent dans chaque base. Vous pouvez insérer des enregistrement et lister tous les enregistrement pour chaque table individuellement. **appadmin** pagine jusqu'à 100 enregistrements en sortie à la fois. +**appadmin** montre quelles bases de données sont disponibles et quelles tables existent dans chaque base. Vous pouvez insérer des enregistrements et lister tous les enregistrements pour chaque table individuellement. **appadmin** pagine jusqu'à 100 enregistrements en sortie à la fois. -Une fois qu'un ensemble d'enregistrements est sélectionné, l'en-tête des pages change, vous autorisant à mettre à jour ou supprimer les enregistrement sélectionnés. +Une fois qu'un ensemble d'enregistrements est sélectionné, l'en-tête des pages change, vous autorisant à mettre à jour ou supprimer les enregistrements sélectionnés. -Pour mettre à jour les enregistrement, entrez une description SQL dans le champ Query string : +Pour mettre à jour les enregistrements, entrez une description SQL dans le champ Query string : `` title = 'test' ``:code From e33ac30520027fffe98790a88367fa9243601f1b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Villoz=20S=C3=A9bastien?= Date: Tue, 26 May 2020 11:02:12 +0200 Subject: [PATCH 3/3] Chapter 4 - French : Translation update/corrections --- .../04.markmin | 89 +++++++++---------- 1 file changed, 44 insertions(+), 45 deletions(-) diff --git a/sources/38-web2py-french-translation-in-progress/04.markmin b/sources/38-web2py-french-translation-in-progress/04.markmin index 1da6973f..d8b5962e 100644 --- a/sources/38-web2py-french-translation-in-progress/04.markmin +++ b/sources/38-web2py-french-translation-in-progress/04.markmin @@ -16,7 +16,7 @@ Pour plus de sécurité, vous pouvez démarrer web2py avec : python web2py.py -a '' -i 127.0.0.1 -p 8000 ``:code -Dans ce cas, web2py ré-utilise le précédent mot de passe en hash stocké. Si aucun mot de passe n'est fourni, ou si le fichier "parameters_8000.py" est supprimé, l'interface web d'administration est désactivée. +Dans ce cas, web2py réutilise le précédent mot de passe en hash stocké. Si aucun mot de passe n'est fourni, ou si le fichier "parameters_8000.py" est supprimé, l'interface web d'administration est désactivée. ``PAM``:inxx Sur certains systèmes Unix/Linux, si le mot de passe est @@ -176,8 +176,8 @@ Ce fichier contient les valeurs par défaut web2py. Si vous éditez ce fichier, ### Workflow Le workflow web2py est le suivant : -- Une requête HTTP arrive au serveur web (le serveur pré-packagé Rocket ou un serveur différent connecté à web2py via WSGI ou un autre adapteur). Le serveur web gère chaque requête dans son propre thread, en parallèle. -- L'en-tête de la requête HTTP est parsée et passée au répartiteur (expliqué plus tart dans ce chapitre). +- Une requête HTTP arrive au serveur web (le serveur pré-packagé Rocket ou un serveur différent connecté à web2py via WSGI ou un autre adaptateur). Le serveur web gère chaque requête dans son propre thread, en parallèle. +- L'en-tête de la requête HTTP est parsée et passée au répartiteur (expliqué plus tard dans ce chapitre). - Le répartiteur décide laquelle des applications installées va gérer la requête et mappe le PATH_INFO dans l'URL en un appel de fonction. Chaque URL correspond à un appel de fonction. - Les requêtes pour les fichiers dans le dossier static sont gérés directement, et les gros fichiers sont automatiquement transmis en flux au client. - Les requêtes pour quelconque fichier sauf un fichier statique sont mappées dans une action (i.e. une fonction dans un fichier contrôleur, dans l'application demandée). @@ -367,7 +367,7 @@ Si l'URL ne requête pas un fichier statique, web2py procède à la requête dan - Parse les cookies. - Créé un environnement dans lequel exécuter la fonction. - Initialise ``request``, ``response``, ``¢ache``. -- Ouvre la ``session`` existante our en créé une nouvelle. +- Ouvre la ``session`` existante ou en créé une nouvelle. - Exécute les modèles appartenant à l'application requêtée. - Exécute la fonction du contrôleur actionnée. - Si la fonction retourne un dictionnaire, exécute la vue associée. @@ -386,7 +386,7 @@ Si l'exception est une exception ``HTTP``, c'est alors supposé avoir le comport ### Librairies -Les librairies web2py sont exposées aux applications utilisateur comme des objets globaux. Par exemple (``request``, ``response``, ``session``, ``cache``), classes (helpers, validators, DAL API), et les functions (``T`` et ``redirect``). +Les librairies web2py sont exposées aux applications utilisateur comme des objets globaux. Par exemple (``request``, ``response``, ``session``, ``cache``), classes (helpers, validators, DAL API), et les fonctions (``T`` et ``redirect``). Ces objets sont définis dans les fichiers coeur suivants ; `` @@ -671,7 +671,7 @@ Les applications développées dans web2py sont composées des parties suivantes - **uploads** les fichiers sont accessibles par les modèles mais pas directement par le développeur (ex. les fichiers uploadés par les utilisateurs de l'application). - **tests** est un répertoire pour stocker les scripts de test, correctifs et maquettes. -Les modèles, vues, contrômeurs, languages, et fichiers statiques sont accessible via l'interface web d'administration [design]. ABOUT, README, et les erreurs sont également accessibles via l'interface d'administration à travers les objets de menu correspondants. Les sessions, cache, modules et fichiers privés sont accessibles par l'application mais ne le sont pas via l'interface d'administration. +Les modèles, vues, contrôleurs, langages, et fichiers statiques sont accessibles via l'interface web d'administration [design]. ABOUT, README, et les erreurs sont également accessibles via l'interface d'administration à travers les objets des menus correspondants. Les sessions, cache, modules et fichiers privés sont accessibles par l'application mais ne le sont pas via l'interface d'administration. Tout est bien organisé dans une structure de répertoire claire répliquée pour toute application web2py installée, afin que l'utilisateur n'ait jamais à accéder directement au systèmes de fichiers : @@ -749,9 +749,9 @@ IS_UPLOAD_FILENAME, IS_UPPER, IS_URL DAL, Field ``:code -Pour une rétro-compatibilité, ``SQLDB=DAL`` et ``SQLField=Field``. Nous vous encourageons à utiliser la nouvelle syntaxe ``DAL`` et ``Field``, plutôt que l'ancienne. +Pour une rétrocompatibilité, ``SQLDB=DAL`` et ``SQLField=Field``. Nous vous encourageons à utiliser la nouvelle syntaxe ``DAL`` et ``Field``, plutôt que l'ancienne. -Les autres objets et modules sont définis dans les librairies, mais ils ne sont pas automatiquement imporés depuis qu'ils ne sont pas utilisés aussi souvent. +Les autres objets et modules sont définis dans les librairies, mais ils ne sont pas automatiquement importés depuis qu'ils ne sont pas utilisés aussi souvent. Les entités du coeur API dans l'environnement d'exécution web2py sont``request``, ``response``, ``session``, ``cache``, ``URL``, ``HTTP``, ``redirect`` et ``T`` et sont présentés ci-après. @@ -771,7 +771,7 @@ from gluon import * En fait, n'importe quel module Python, même s'il n'est pas importé par une application web2py, peut importer les API web2py aussi longtemps que web2py est dans ``sys.path``. -Il y a tout de même une mise en garde, web2py définit quelques objets globaux (request, response, session, cache, T) qui peuvent uniquement exister lorsqu'une requête HTTP est présente (ou est simulée). Par conséquent, les modules peuvent y accéder sulement s'ils sont appelés depuis une application. Pour ces raisons, ils sont placés dans un conteneur appelé ``current``, qui est un fil d'objet local. Voici un exemple : +Il y a tout de même une mise en garde, web2py définit quelques objets globaux (request, response, session, cache, T) qui peuvent uniquement exister lorsqu'une requête HTTP est présente (ou est simulée). Par conséquent, les modules peuvent y accéder seulement s'ils sont appelés depuis une application. Pour ces raisons, ils sont placés dans un conteneur appelé ``current``, qui est un fil d'objet local. Voici un exemple : Créez un module "/myapp/modules/test.py" qui contient : `` @@ -825,7 +825,7 @@ et maintenant tous les modules importés peuvent accéder à ``current.auth``. ``current`` et ``import`` créent un puissant mécanisme pour construire des modules extensibles et réutilisables pour vos applications. ------- -Attention ! Etant donné ``from.gluon import current``, il est correct d'utiliser ``current.request`` et n'importe quel autre object local du thread sauf un ne devrait jamais les assigner à des variables globales dans le modules, tel que dans +Attention ! Etant donné ``from.gluon import current``, il est correct d'utiliser ``current.request`` et n'importe quel autre objet local du thread sauf un ne devrait jamais les assigner à des variables globales dans le modules, tel que dansquelques uns `` request = current.request # WRONG! DANGER! `` @@ -872,7 +872,7 @@ my_other_storage = Storage(dict(a=1, b=2)) # convert dictionary to Storage ``:code ----- -``request`` a les objets/attributs suivants, quelques uns sont également une instance de la classe ``Storage`` : +``request`` a les objets/attributs suivants, quelques-uns sont également une instance de la classe ``Storage`` : - ``request.cookies``: un objet ``Cookie.SimpleCookie()`` contenant les cookies passés avec la requête HTTP. Il agit comme un dictionnaire de cookies. Chaque cookie est un objet Morsel ``morsel``:cite. - ``request.env``: un objet ``Storage`` contenant les variables d'environnement passées au contrôleur, incluant les variables d'en-tête HTTP depuis la requête HTTP et les paramètres standards WSGI. Les variables d'environnement sont toutes converties en minuscules, et les points sont convertis en underscores pour une meilleure mémorisation. - ``request.application``: le nom de l'application demandée. @@ -1004,7 +1004,7 @@ Notez également les variables ``request.env.wsgi_*``. Elles sont spécifiques - ``response.files``: une liste de fichiers ``.css``, ``.js``, ``.coffee``, et ``.less`` requis par la page. Ils seront automatiquement liés dans la tête du standard "layout.html" via le fichier inclus "web2py_ajax.html". Pour inclure un nouveau fichier CSS, JS, COFFEE ou JS, ajoutez le simplement à la liste. Ceci évitera les duplications. L'ordre est important. - ``response.include_files()`` génère les tags HTML d'en-tête pour inclure tous les ``response.files`` (utilisés dans "views/web2py_ajax.html"). - ``response.flash``: paramètre optionnel qui peut être inclus dans les vues. Normalement utilisé pour notifier l'utilisateur au sujet de quelque chose qui s'est produit. -- ``response.headers``: un ``dict`` pour les en-têtes de réponse HTTP. Web2py définit quelques en-têtes par défaut, incluant "Content-Length", "Content-Type", et "X-Powered-By" (défini comme web2py). Web2py définit également les en-têtes "Cache-Control", "Expires", et "Pragma" pour éviter le cache côté client, exceptées les requếtes pour les fichiers statiques, pour lesquelles les mécanismes de cache sont activés. Les en-têtes que web2py définir peuvent être surchargées ou supprimées, et de nouveaux en-têtes peuvent être ajoutés (e.g., ``response.headers['Cache-Control'] = 'private'``). Vous pouvez supprimer un en-tête en supprimant sa clé du dictionnaire response.headers (e.g. ``del response.headers['Custom-Header']``), cependant les en-têtes par défaut de web2py seront ré-ajoutés juste avant de renvoyer la réponse. Pour éviter ce comportement, définissez juste la valeur de l'en-tête à None (e.g., pour supprimer l'en-tête Content-Type, ``response.headers['Content-Type'] = None``). +- ``response.headers``: un ``dict`` pour les en-têtes de réponse HTTP. Web2py définit quelques en-têtes par défaut, incluant "Content-Length", "Content-Type", et "X-Powered-By" (défini comme web2py). Web2py définit également les en-têtes "Cache-Control", "Expires", et "Pragma" pour éviter le cache côté client, exceptées les requêtes pour les fichiers statiques, pour lesquelles les mécanismes de cache sont activés. Les en-têtes que web2py définir peuvent être surchargées ou supprimées, et de nouveaux en-têtes peuvent être ajoutés (e.g., ``response.headers['Cache-Control'] = 'private'``). Vous pouvez supprimer un en-tête en supprimant sa clé du dictionnaire response.headers (e.g. ``del response.headers['Custom-Header']``), cependant les en-têtes par défaut de web2py seront ré-ajoutés juste avant de renvoyer la réponse. Pour éviter ce comportement, définissez juste la valeur de l'en-tête à None (e.g., pour supprimer l'en-tête Content-Type, ``response.headers['Content-Type'] = None``). - ``response.menu``: paramètre optionnel qui peut être inclus dans les vues, normalement utilisé pour passer un menu de navigation en arbre à la vue. Il peut être affiché par l'helper MENU. - ``response.meta``: un objet Storage qui contient les informations ```` telles que ``response.meta.author``, ``.description``, et/ou ``.keywords``. Le contenu de chaque variable meta est automatiquement placé dans le tag ``META`` correspondant par le code dans "views/web2py_ajax.html", qui est inclus par défaut dans "views/layout.html". - ``response.include_meta()`` génère une chaîne qui inclut tous les en-têtes ``response.meta`` sérialisés (utilisés dans "views/web2py_ajax.html"). @@ -1199,7 +1199,7 @@ def cache_in_ram_and_disk(): return dict(time=t, link=A('click me', _href=request.url)) ``:code -La sortie de ``lambda: time.ctime()`` est mise en cache sur le disque (en utilisant le module shelve) et ensuite en RAM pour 5 secondes. web2py regarde d'abord en RAM puis ensuite sur le disque s'il ne trouve rien. Si ce n'est ni en RAM ni sur le disque, ``lambda: time.ctime()`` est exécuté et le cache est mis à jour. Cette technique est utile dans un environnement multi-processeur. Les deux fois n'ont pas à être les mêmes. +La sortie de ``lambda: time.ctime()`` est mise en cache sur le disque (en utilisant le module shelve) et ensuite en RAM pour 5 secondes. web2py regarde d'abord en RAM puis ensuite sur le disque s'il ne trouve rien. Si ce n'est ni en RAM ni sur le disque, ``lambda: time.ctime()`` est exécuté et le cache est mis à jour. Cette technique est utile dans un environnement multiprocesseurs. Les deux fois n'ont pas à être les mêmes. L'exemple suivant met en cache (en RAM) la sortie de la fonction contrôleur (mais pas la vue) : @@ -1237,7 +1237,7 @@ def cache_controller_and_view(): d = dict(time=t, link=A('click to reload', _href=request.url)) return response.render(d) ``:code -``response.render(d)`` returns the rendered view as a string, which is now cached for 5 seconds. This is the best and fastest way of caching. +``response.render(d)`` retourne la vue rendue comme une string, cette dernière est mis en cache pour 5 secondes. Cette méthode est la meilleure et la plus rapide pour mettre des valeurs en cache. ------ Nous recommandons l'utilisation de [[@cache.action #cache_action]] à partir de web2py > 2.4.6 ------ @@ -1292,7 +1292,7 @@ Ceci est possible en envoyant certains en-têtes spécifiques avec la page : lor Web2py > 2.4.6 a introduit un nouveau décorateur ``cache.action`` pour autoriser un moyen plus intelligent de gérer cette situation. ``cache.action`` peut être utilisé : -- pour définir des en-têtes de cache intélligents +- pour définir des en-têtes de cache intelligents - pour mettre en cache les résultats en conséquence ------ NB: il fera l'un ou l'autre ou **les deux**. @@ -1340,7 +1340,7 @@ A utiliser à bon escient ! [[URL]] ### ``URL`` ``URL``:inxx -La fonction ``URL`` is l'une des fonctions les plus importantes dans web2py. Elle génère des URL internes pour les actions et les fichiers statiques. +La fonction ``URL`` est l'une des fonctions les plus importantes dans web2py. Elle génère des URL internes pour les actions et les fichiers statiques. Voici un exemple : @@ -1354,9 +1354,9 @@ est traduit en /[application]/[controller]/f ``:code -Notez que la sortie de la fonction ``URL``dépend du nom de l'application courante, du contrôleur appelant, et d'autres paramètres. web2py supporte le mapping d'URL de d'URL inverse. Le mapping URL vous permet de redéfinir le format des URLs externes. Si vous utilisez la fonction ``URL`` pour générer toutes les URLs internes, alors les ajouts et modifications aux mapping URL éviteront les liens brisés à l'intérieur d'une application web2py. +Notez que la sortie de la fonction ``URL`` dépend du nom de l'application courante, du contrôleur appelant, et d'autres paramètres. web2py supporte le mapping d'URL de d'URL inverse. Le mapping URL vous permet de redéfinir le format des URLs externes. Si vous utilisez la fonction ``URL`` pour générer toutes les URLs internes, alors les ajouts et modifications aux mapping URL éviteront les liens brisés à l'intérieur d'une application web2py. -Vous pouvez transmettre des paramètres additionels à la fonction ``URL``, i.e., des arguments dans le chemin URL (args) et des variables (vars) : +Vous pouvez transmettre des paramètres additionnels à la fonction ``URL``, i.e., des arguments dans le chemin URL (args) et des variables (vars) : `` URL('f', args=['x', 'y'], vars=dict(z='t')) @@ -1422,7 +1422,6 @@ est interprété en ``:code Si le fichier statique est dans un sous-dossier du dossier ``static``, vous pouvez inclure le(s) sous-dossier(s) dans le nom du fichier. Par exemple, pour générer : -If the static file is in a subfolder within the ``static`` folder, you can include the subfolder(s) as part of the filename. For example, to generate: `` /[application]/static/images/icons/arrow.png @@ -1436,7 +1435,7 @@ URL('static', 'images/icons/arrow.png') Vous n'avez pas besoin d'encoder/échapper les arguments ``args`` et ``vars`` ; ceci est fait automatiquement pour vous. -Par défaut, l'extension correspondant à la requête courante (qui peut être trouvée dans ``request.extension``) est ajoutée à la fonction, à moins que request.extension soit html, la valeur par défaut. Ceci peut être surchargé en incluant explicitement un extension dans le nom de la fonction ``URL(f='name.ext')`` ou avec l'argument extension : +Par défaut, l'extension correspondant à la requête courante (qui peut être trouvée dans ``request.extension``) est ajoutée à la fonction, à moins que request.extension soit html, la valeur par défaut. Ceci peut être surchargé en incluant explicitement une extension dans le nom de la fonction ``URL(f='name.ext')`` ou avec l'argument extension : `` URL(..., extension='css') ``:code @@ -1610,7 +1609,7 @@ a = T("hello %(name)s") % dict(name='Tim') La dernière syntaxe est recommandée car elle permet de rendre la traduction plus simple. La première chaîne est traduite selon le fichier de langue demandé et la variable ``name`` est remplacée indépendamment du langage. -Vous poupvez concaténer des chaînes traduites avec des chaînes normales : +Vous pouvez concaténer des chaînes traduites avec des chaînes normales : `` T("blah ") + name + T(" blah") ``:code @@ -1667,7 +1666,7 @@ T.lazy = False Par ce moyen, les chaînes sont traduites immédiatement par l'opérateur ``T`` basé sur la langue actuellement acceptée ou la langue forcée. -Il est égaleemnt possible de désactiver l'évaluation discrète pour chaque chaîne individuellement : +Il est également possible de désactiver l'évaluation discrète pour chaque chaîne individuellement : `` T("Hello World", lazy=False) @@ -1709,7 +1708,7 @@ empêche T de mettre à jour dynamiquement les fichiers de langage. #### Commentaires et traductions multiples -Il est possible que la même chaine apparaisse sous différents contextes dans l'application et ait besoin besoin de différentes traductions selon le contexte. Afin de faire ceci, il est possible d'ajouter des commentaires à la chaine originale. Les commentaires ne seront pas affichés mais seront utilisés par web2py pour déterminer la traduction la plus appropriée. Par exemple : +Il est possible que la même chaine apparaisse sous différents contextes dans l'application et ait besoin de différentes traductions selon le contexte. Afin de faire ceci, il est possible d'ajouter des commentaires à la chaine originale. Les commentaires ne seront pas affichés mais seront utilisés par web2py pour déterminer la traduction la plus appropriée. Par exemple : `` T("hello world ## first occurrence") @@ -1746,7 +1745,7 @@ Le résultat en Anglais sera : "You have 10 books". Notez bien que "book" a ét Le PS consiste en 3 parties : - les espaces réservés ``%%{}`` pour marquer les mots dans l'invite ``T`` - une règle pour donner une décision sur la forme de mot à utiliser ("rules/plural_rules/*.py") -- un dictionaire avec des formes de mot au pluriel ("app/languages/plural-*.py") +- un dictionnaire avec des formes de mot au pluriel ("app/languages/plural-*.py") La valeur des symboles peut être une simple variable, une liste/tuple de variables, ou un dictionnaire. @@ -1828,7 +1827,7 @@ var output ... `` -Inside ``%%{...}`` you can also use the following modifiers: +Dans ``%%{...}`` vous pouvez également modifier selon la syntaxe ci-dessous : - ``!`` pour mettre en lettres capitales le texte (équivalent à ``string.capitalize``) - ``!!`` pour mettre en lettres capitales chaque mot (équivalent à ``string.title``) @@ -1860,7 +1859,7 @@ web2py utilise les modules de cookies Python pour gérer les cookies. Les cookies en provenance du navigateur sont stockés dans ``request.cookies`` et les cookies envoyés par le serveur sont dans ``response.cookies``. -Vous pouvez définir un cookie come suit : +Vous pouvez définir un cookie comme ci-dessous : `` response.cookies['mycookie'] = 'somevalue' response.cookies['mycookie']['expires'] = 24 * 3600 @@ -1938,7 +1937,7 @@ Notez que si vous éditez routes.py, vous devez recharger web2py. Ceci peut êtr Le routeur "parameter-based" fournit un accès simplifié à de nombreuses méthodes de réécriture d'URL embarquées. Ses possibilités incluent : -- Oubli de l'application par défaut, du contrôleur et des noms de fonction avec des URLs visibles depuis l'extérieur (celles créées par la fonctionr URL()) +- Oubli de l'application par défaut, du contrôleur et des noms de fonction avec des URLs visibles depuis l'extérieur (celles créées par la fonction URL()) - Mapping de domaines (et/ou de ports) pour les applications et les contrôleurs - Embarquer un sélecteur de langue dans l'URL - Supprimer un préfixe fixé depuis les URLs entrantes et l'ajouter aux URLs sortantes @@ -1961,7 +1960,7 @@ ou `` http://domain.com/myapp/myapp/index ``:code -où le raccourci serait ambigu. Si vous avez deux applications, ``myapp`` et ``myapp2``, vous obtiendrez le même effet, et en plus le contrôleur par défaut de ``myapp2`` sera enlevée de l'URL à chaque fois qu'il est sûr (cas le plus fréquent, quasi tout le temps). +où le raccourci serait ambigu. Si vous avez deux applications, ``myapp`` et ``myapp2``, vous obtiendrez le même effet, et en plus le contrôleur par défaut de ``myapp2`` sera enlevé de l'URL à chaque fois qu'il est sûr (cas le plus fréquent, quasi tout le temps). Voici un autre cas : supposons que vous voulez supporter les langues en se basant sur l'URL, où les URLs ressemblent à : `` @@ -2107,7 +2106,7 @@ S'il y a plusieurs routes, la première à correspondre à l'URL est exécutée. Vous pouvez utiliser ``$anything`` pour faire correspondre n'importe quoi (``.*``) jusqu'à la fin de la ligne. -Voici un version minimale de "routes.py" pour gérer le favicon et les requêtes de robots : +Voici une version minimale de "routes.py" pour gérer le favicon et les requêtes de robots : ``favicon``:inxx ``robots``:inxx `` @@ -2118,7 +2117,7 @@ routes_in = ( routes_out = () ``:code -Voici un exemple plus comlpexe qui expose une simple application "myapp" sans préfixe non nécessaire mais qui expose aussi **admin**, **appadmin** et static: +Voici un exemple plus complexe qui expose une simple application "myapp" sans préfixe non nécessaire mais qui expose aussi **admin**, **appadmin** et static: `` routes_in = ( @@ -2131,7 +2130,7 @@ routes_in = ( routes_out = [(x, y) for (y, x) in routes_in[:-2]] ``:code -La syntaxe générale pour les routes est plus complexe que les simples exemples que nous avons vu jusqu'ici. Voici un exemple plus général et représentatif : +La syntaxe générale pour les routes est plus complexe que les simples exemples que nous avons vus jusqu'ici. Voici un exemple plus général et représentatif : `` routes_in = ( ('140\.191\.\d+\.\d+:https?://www.web2py.com:post /(?P.*)\.php', @@ -2243,7 +2242,7 @@ Si l'``error_handler`` est spécifié, l'action est appelée sans redirection ut Depuis la version 2.1.0, web2py a la possibilité de gérer les actifs statiques. -Lorsqu'une application est en développement, un fichier statique peut souvent changer, donc web2py envoie les fichiers statiques sans en-têtes entraînant le cache. Ceci a pour effet de bord de "forcer" le navigateur à envoyer ses requêtes de fichiers statiques à chaque requête. Ceci résulte en de plsu faibles performance lors du chargement d'une page. +Lorsqu'une application est en développement, un fichier statique peut souvent changer, donc web2py envoie les fichiers statiques sans en-têtes entraînant le cache. Ceci a pour effet de bord de "forcer" le navigateur à envoyer ses requêtes de fichiers statiques à chaque requête. Ceci résulte en de plus faibles performances lors du chargement d'une page. Sur un site de "production", vous pouvez vouloir servir les fichiers statiques avec des en-têtes gérant le ``cache`` afin de vous prémunir de téléchargements inutiles puisque les fichiers statiques sont inchangés. @@ -2255,7 +2254,7 @@ Une approche manuelle consiste à la création de sous-dossiers pour différente Cette procédure fonctionne mais est lourde puisqu'à chaque modification du fichier css, vous devez vous souvenir de le déplacer vers un autre dossier, changer l'URL du fichier dans le layout.html et déployer. -La gestion des actifs statiques résoud le problème en autorisant le développeur à déclarer une version pour un groupe de fichiers statiques et qui ne seront alors requêtés uniquement lorsque le numéro de version change. Le numéro de version fait partie de l'URL du fichier comme dans l'exemple précedent. La différence de l'approche précédente est que ce numéro de version n'apparaît que dans l'URL et non dans le système de fichiers. +La gestion des actifs statiques résout le problème en autorisant le développeur à déclarer une version pour un groupe de fichiers statiques et qui ne seront alors requêtés uniquement lorsque le numéro de version change. Le numéro de version fait partie de l'URL du fichier comme dans l'exemple précèdent. La différence de l'approche précédente est que ce numéro de version n'apparaît que dans l'URL et non dans le système de fichiers. Si vous voulez fournir "/myapp/static/layout.css" avec les en-têtes de cache, vous avez juste besoin d'inclure le fichier avec une URL différence qui inclut le numéro de version : `` @@ -2332,7 +2331,7 @@ Les tâches en queue "maison" peuvent être une alternative plus simple au sched #### Cron ``cron``:inxx -Le cron web2py fournit la possibilité pour les application d'exécuter des tâches à des heures pré-déterminées, dans une plateforme indépendante. +Le cron web2py fournit la possibilité pour les application d'exécuter des tâches à des heures prédéterminées, dans une plateforme indépendante. Pour chaque application, la fonctionnalité de cron est définie par un fichier crontab : @@ -2363,11 +2362,11 @@ Les deux dernières lignes dans cet exemple utilisent des extensions à la synta Le fichier "applications/admin/cron/expire_sessions.py" existe en fait et est livré avec l'application **admin**. Il vérifie les sessions expirées et les supprime. "applications/admin/cron/crontab" démarre cette tâche toutes les heures. ------- -Si la tâche/script est préfixé avec une astérisque (``*``) et finit avec ``.py``, il sera exécuté automatiquement dans l'environnement web2py. Cela signifie que vous aurez tous les contrôleurs et modèles à votre disposition. Si vous utilisez 2 asrésiques (``**``), les modèles ne seront pas exécutés. C'est le meilleur moyen de les utiliser, puisqu'il y a un minimum de surcharge evitant ainsi d'éventuels problèmes de verrou. +Si la tâche/script est préfixé avec une astérisque (``*``) et finit avec ``.py``, il sera exécuté automatiquement dans l'environnement web2py. Cela signifie que vous aurez tous les contrôleurs et modèles à votre disposition. Si vous utilisez 2 astérisques (``**``), les modèles ne seront pas exécutés. C'est le meilleur moyen de les utiliser, puisqu'il y a un minimum de surcharge évitant ainsi d'éventuels problèmes de verrou. Notez que les scripts/fonctions exécutées dans l'environnement web2py nécessite un ``db.commit()`` manuel à la fin de la fonction pour que la transaction ne soit pas annulée. -web2py ne génère pas de tickets ou de tracebacks explicatifs en mode shell, ce qui est le fonctionnement du cron, donc assuez-vous qeu votre code web2py s'exécute sans erreur avant de le définir comme tâche cron étant donné que vous ne serez pas en mesure de voir ces erreurs lorsque l'exécution se fera depuis le cron. De plus, soyez attentifs à la manière dont vous utilisez les modèles : lorsqu'une exécution se produit dans un process séparé, les verrous à la base de données doivent être pris en compte afin d'éviter les pages d'attendre les tâches cron qui pourraient bloquer la base de données. Utilisez la syntaxe ``**`` si vous n'avez pas besoin d'utiliser la base de données dans votre tâche cron. +web2py ne génère pas de tickets ou de tracebacks explicatifs en mode shell, ce qui est le fonctionnement du cron, donc assurez-vous que votre code web2py s'exécute sans erreur avant de le définir comme tâche cron étant donné que vous ne serez pas en mesure de voir ces erreurs lorsque l'exécution se fera depuis le cron. De plus, soyez attentifs à la manière dont vous utilisez les modèles : lorsqu'une exécution se produit dans un process séparé, les verrous à la base de données doivent être pris en compte afin d'éviter les pages d'attendre les tâches cron qui pourraient bloquer la base de données. Utilisez la syntaxe ``**`` si vous n'avez pas besoin d'utiliser la base de données dans votre tâche cron. Vous pouvez également appeler une fonction contrôleur, auquel cas il n'y a pas besoin de spécifier un chemin. Le contrôleur et la fonction seront ceux de l'application appelante. Faites particulièrement attention aux failles listées ci-dessus. Par exemple : `` @@ -2398,7 +2397,7 @@ Exemple de ligne à ajouter au système crontab, (habituellement /etc/crontab) : 0-59/1 * * * * web2py cd /var/www/web2py/ && python web2py.py -J -C -D 1 >> /tmp/cron.output 2>&1 ``:code -Avec le ``cron`` externe, assurez vous d'ajouter soit ``-J`` (ou ``-cronjob``, qui revient au même) comme indiqué au-dessus afin que web2py sache que la tâche est exécutée par le cron. Web2py définit ceci de manière interne avec le soft et le hard ``cron``. +Avec le ``cron`` externe, assurez-vous d'ajouter soit ``-J`` (ou ``-cronjob``, qui revient au même) comme indiqué au-dessus afin que web2py sache que la tâche est exécutée par le cron. Web2py définit ceci de manière interne avec le soft et le hard ``cron``. #### File d'attente de tâches maison @@ -2773,7 +2772,7 @@ Un exemple est bien meilleur qu'un millier de mots : ``scheduler.terminate('high Attention : si vous avez un worker exécutant ``high_prio`` et ``low_prio``, ``scheduler.terminate('high_prio')`` terminera tous les workers ensemble, même si vous ne souhaitiez pas terminer les ``low_prio``. ------ -Tout ce qu'il est possible de faire via appadmin peut être fait en programmation en insérant/mettant à jour les enregistrement dans ces tables. +Tout ce qu'il est possible de faire via appadmin peut être fait en programmation en insérant/mettant à jour les enregistrements dans ces tables. Peu importe, les enregistrements relatifs aux tâches ``RUNNING`` ne devraient pas être mises à jour puisque cela peut engendrer un comportement non voulu. La bonne pratique est de mettre en attente des tâches en utilisant la méthode "queue_task". @@ -2844,7 +2843,7 @@ et vous pouvez ensuite l'importer dans n'importe quel modèle/contrôleur/vue av import matplotlib ``:code -La distribution des sources web2py, et la disctribution binaire Windows ont un site-packages dans le répertoire de haut-niveau. La distribution binaire Mac a un répertoire site-packages dans le répertoire : +La distribution des sources web2py, et la distribution binaire Windows ont un site-packages dans le répertoire de haut-niveau. La distribution binaire Mac a un répertoire site-packages dans le répertoire : ``web2py.app/Contents/Resources/site-packages``:code @@ -2868,7 +2867,7 @@ Alors que tout ce qui est décrit ici fonctionne bien, nous recommandons plutôt Les fichiers de modèle et de contrôleur web2py ne sont pas des modules Python et ne peuvent pas être importés en utilisant la déclaration Python ``import``. La raison de cela est que les modèles et les contrôleurs sont voués à être exécutés dans un environnement préparé qui a été pré-rempli avec des objets globaux web2py (request, response, session, cache et T) et des fonctions helper. Ceci est nécessaire puisque Python est un langage considéré statique, alors que l'environnement web2py est créé dynamiquement. -web2py fournit la fonction ``exec_environment`` pour vous permettre d'accéder aux modèles et aux contrôleurs directement. ``exec_environment`` créé un environnemnet d'exécution web2py, charge le fichier et retourne ensuite un objet Storage contenant l'environnemnet. L'objet Storage sert également de mécanisme d'espace de nom. Tout fichier Python désigné à être exécuté dans un environnement d'exécution peut être chargé en utilisant ``exec_environment``. Les utilisation pour ``exec_environment`` incluent : +web2py fournit la fonction ``exec_environment`` pour vous permettre d'accéder aux modèles et aux contrôleurs directement. ``exec_environment`` créé un environnement d'exécution web2py, charge le fichier et retourne ensuite un objet Storage contenant l'environnement. L'objet Storage sert également de mécanisme d'espace de nom. Tout fichier Python désigné à être exécuté dans un environnement d'exécution peut être chargé en utilisant ``exec_environment``. Les utilisation pour ``exec_environment`` incluent : - Accéder aux données (modèles) depuis les autres applications. - Accéder aux objets globaux depuis les autres modèles ou contrôleurs. - Exécuter les fonctions de contrôleur depuis les autres contrôleurs. @@ -2881,7 +2880,7 @@ cas = exec_environment('applications/cas/models/db.py') rows = cas.db().select(cas.db.user.ALL) ``:code -Un autr exemple : supposez que vous ayez un contrôleur "other.py" qui contient : +Un autre exemple : supposez que vous ayez un contrôleur "other.py" qui contient : `` def some_action(): return dict(remote_addr=request.env.remote_addr) @@ -2905,11 +2904,11 @@ Un dernier avertissement : n'utilisez pas ``exec_environement`` de manière inap Il y a de nombreux moyens de faire coopérer des applications : - Les application peuvent se connecter à la même base et donc partager des tables. Il n'est pas nécessaire que toutes les tables dans la base soient définies par toutes les applications, mais elles peuvent être définies par les application qui les utilisent. Toutes les applications qui utilisent la même table, sauf une, doivent définir la table avec ``migrate=False``. -- Les application peuvent embarquer des composants depuis d'autres applications en utilisant le helper LOAD (décrit dans le chapitre 12). +- Les applications peuvent embarquer des composants depuis d'autres applications en utilisant le helper LOAD (décrit dans le chapitre 12). - Les applications peuvent partager des sessions. - Les applications peuvent s'appeler à distance à travers XML-RPC. -- Les applications peuvenet accéder aux fichiers des autres via le système de fichiers (en supposant qu'ils partagent le même système de fichiers). -- Les application peuvent appeler d'autres actions localement en utilisant ``exec_environment`` comme présenté juste au-dessus. +- Les applications peuvent accéder aux fichiers des autres via le système de fichiers (en supposant qu'ils partagent le même système de fichiers). +- Les applications peuvent appeler d'autres actions localement en utilisant ``exec_environment`` comme présenté juste au-dessus. - Les applications peuvent importer des modules d'une autre application en utilisant la syntaxe : `` from applications.otherapp.modules import mymodule @@ -2958,7 +2957,7 @@ http://docs.python.org/library/logging.html `` La chaîne "web2py.app.myapp" définit un logger de niveau application. -Pour que ceci fonctione correctement, vous avez besoin d'un fichier de configuration pour le logger. +Pour que ceci fonctionne correctement, vous avez besoin d'un fichier de configuration pour le logger. L'un est fourni par web2py dans le dossier "examples" : "logging.example.conf". Vous aurez besoin de copier ce fichier vers le répertoire web2py et de le renommer en "logging.conf" puis de le personnaliser comme vous le souhaitez. Ce fichier est auto-documenté, donc vous devriez l'ouvrir et le lire.