From 2fd00de2170fcb16b5214c7839c18f0dacab8cdb Mon Sep 17 00:00:00 2001 From: tof <> Date: Fri, 31 Aug 2007 09:58:35 +0000 Subject: Full translation of Blog Tutorial in French. Thanks to Eric.M ! --- .../protected/pages/Day1/fr/CreateContact.page | 203 +++++++++++++++++++++ .../protected/pages/Day1/fr/Setup.page | 161 ++++++++++++++++ .../protected/pages/Day1/fr/ShareLayout.page | 182 ++++++++++++++++++ .../protected/pages/Day1/fr/directories.gif | Bin 0 -> 3611 bytes .../protected/pages/Day1/fr/directories2.gif | Bin 0 -> 4147 bytes .../protected/pages/Day1/fr/directories3.gif | Bin 0 -> 3531 bytes .../protected/pages/Day1/fr/output.gif | Bin 0 -> 13379 bytes 7 files changed, 546 insertions(+) create mode 100755 demos/blog-tutorial/protected/pages/Day1/fr/CreateContact.page create mode 100755 demos/blog-tutorial/protected/pages/Day1/fr/Setup.page create mode 100755 demos/blog-tutorial/protected/pages/Day1/fr/ShareLayout.page create mode 100755 demos/blog-tutorial/protected/pages/Day1/fr/directories.gif create mode 100755 demos/blog-tutorial/protected/pages/Day1/fr/directories2.gif create mode 100755 demos/blog-tutorial/protected/pages/Day1/fr/directories3.gif create mode 100755 demos/blog-tutorial/protected/pages/Day1/fr/output.gif (limited to 'demos/blog-tutorial/protected/pages/Day1') diff --git a/demos/blog-tutorial/protected/pages/Day1/fr/CreateContact.page b/demos/blog-tutorial/protected/pages/Day1/fr/CreateContact.page new file mode 100755 index 00000000..e85d8bfe --- /dev/null +++ b/demos/blog-tutorial/protected/pages/Day1/fr/CreateContact.page @@ -0,0 +1,203 @@ + + +

Création de la page Contact

+ +

+Nous avons créé une page par défaut Home.page en utilisant les outils en ligne de commande de PRADO. Cette page est relativement statique parce qu'elle ne contient que du contenu HTML. Dans cette session, nous allons créer une page dynamique dénommée Contact. +

+ +

+Le but de cette page est de collecter les retours d'informations des utilisateurs Web concernant notre outil de blog. Pour atteindre ce but, nous envisageons d'utiliser un formulaire qui sera à remplir. Dans ce formulaire, nous demanderons le nom de l'utilisateur, son adresse email et son commentaire. Après que le formulaire ai été rempli et envoyé, un email avec le commentaire sera envoyé à l'administrateur. +

+ +

+Pour créer la page Contact, nous avons besoin de 2 fichiers dans le dossier pages : le fichier de gabarit Contact.page et le fichier de classe PHP Contact.PHP. +

+ + + + +Une page doit avoir un fichier de gabarit (extension .page) ou un fichier de classe PHP, ou les deux : +

+ + +
+ + +

Création de la page gabarit

+ +

+Nous allons premièrement créer le fichier gabarit de la page Contact. +

+ +

+Nous utilisons un fichier gabarit pour organiser la présentation de notre formulaire. Dans notre gabarit, nous utilisons des champs de saisie pour collecter le nom de l'utilisateur, son email et son commentaire. D'autre part, nous utilisons des validateurs pour nous assurer que l'utilisateur a bien fourni les éléments avant d'envoyer le formulaire. Le contenu complet du gabarit est le suivant, +

+ + + +Mon Blog - Contact + +

Contact

+

Veuillez remplir le formulaire suivant pour me laisser vos impressions au sujet de mon blog. Merci !

+ +<com:TForm> + +Votre nom: +<com:TRequiredFieldValidator ControlToValidate="Name" + ErrorMessage="Veuillez indiquer votre nom." + Display="Dynamic" /> +
+<com:TTextBox ID="Name" /> + +
+Votre email: +<com:TRequiredFieldValidator ControlToValidate="Email" + ErrorMessage="Veuillez indiquer votre email." + Display="Dynamic" /> +<com:TEmailAddressValidator ControlToValidate="Email" + ErrorMessage="Vous avez saisi un email invalide." + Display="Dynamic" /> +
+<com:TTextBox ID="Email" /> + +
+Commentaires: +<com:TRequiredFieldValidator ControlToValidate="Feedback" + ErrorMessage="Veuillez saisir un commentaire." + Display="Dynamic" /> +
+<com:TTextBox ID="Feedback" + TextMode="MultiLine" + Rows="10" + Columns="40" /> + +
+<com:TButton Text="Envoyer" OnClick="submitButtonClicked" /> + +</com:TForm> + + + +
+ +

+Comme vous pouvez le voir, un fichier gabarit ressemble énormément à un fichier HTML classique. La principale différence concerne le fichier gabarit qui contient quelques balises <com:>. Chaque balise <com:> fait référence à un contrôle dont les propriétés sont initialisées grâce aux paires nom-valeur de la balise. Par exemple, la balise <com:TButton> fait référence au contrôle TButton qui affiche un bouton permettant à l'utilisateur de soumettre le formulaire. Pour une syntaxe complète, veuillez vous référer au Tutoriel de démarrage rapide. + + +PRADO fournit un contrôle pour chaque type de balise HTML. Par exemple, TTextBox affiche un champ de saisie, TDropDownList affiche une liste déroulante. Chaque contrôle est un composant auquel on peut accéder par code et dont les propriétés sont modifiables. + + + +

+Avant le contrôle TTextBox, le gabarit utilise aussi plusieurs validateurs qui permettent de s'assurer que les données saisies sont bien conformes à notre attente. Par exemple, pour nous assurer que l'adresse email est valide, nous utilisons les deux validateurs suivants, +

+ + +Your Email: +<com:TRequiredFieldValidator + ControlToValidate="Email" + ErrorMessage="Veuillez indiquer votre email." + Display="Dynamic" /> +<com:TEmailAddressValidator + ControlToValidate="Email" + ErrorMessage="Vous avez saisi un email invalide." + Display="Dynamic" /> +
+<com:TTextBox ID="Email" /> +
+
+ +

+Ci-dessous, un résumé des contrôles utilisés dans le gabarit : +

+ + + + +Ecrire des gabarits seulement avec un éditeur de texte peut être pénible et pas vraiment intuitif pour les designers. Pour faciliter ceci, PRADO inclus dans cette version, une extension pour Dreamweaver qui permet la complétion automatique des balises PRADO (ceci inclut le nom des balises, le nom des propriétés, le nom des évènements, etc.). + + +

Création du fichier de classe PHP

+ +

+Nous allons maintenant créer le fichier de classe PHP Contact.PHP. Ce fichier est nécessaire parce que nous devons agir après la soumission du formulaire. +

+ +

+Notez les lignes dans le fichier gabarit. Elles indiquent que lorsque l'utilisateur soumet le formulaire, la méthode submitButtonClicked() doit être appelé. Ici, OnClick est le nom de l'évènement et la méthode correspondante doit être défini dans le fichier de classe PHP. +

+ + + <com:TButton Text="Submit" OnClick="submitButtonClicked" /> + + +

+Nous écrirons donc le fichier de classe suivant : +

+ + +IsValid) // vérifie que les validations sont Ok + { + // récupère le nom de l'utilisateur, son email et son commentaire + $name = $this->Name->Text; + $email = $this->Email->Text; + $feedback = $this->Feedback->Text; + + // envoie un email à l'administrateur avec les informations + $this->mailFeedback($name, $email, $feedback); + } + } + + protected function mailFeedback($name, $email, $feedback) + { + // implémentation de l'envoi de l'email + } +} +?> + + +

+Le code précédent est largement explicite. En fait, nous avons juste montré le principe d'un gestionnaire d'évènement. Dans le gestionnaire d'évènement submitButtonClicked(), nous récupérons les éléments saisies par l'utilisateur. Par exemple, $this->Name->Text retourne la valeur de la propriété Text du contrôle Name qui est un contrôle permettant la saisie du nom de l'utilisateur. +

+ + +Le nom de la classe héritant de TPage doit être le même que le nom du fichier. C'est aussi une nécessité pour écrire n'importe quelle classe de composant PRADO. + + +

Test

+ +

+Notre nouvelle page Contact peut être testée en naviguant à l'URL http://hostname/blog/index.PHP?page=Contact. Si vous cliquez sur le bouton "envoyer" sans avoir saisi de données, vous verrez apparaitre des messages d'erreurs à côté des champs de saisie. Si vous entrez toutes les informations nécessaires, la méthode mailFeedback() sera appelée. +

+ + + +

+Une amélioration possible à notre page serait d'afficher un message de confirmation après que l'utilisateur ai envoyé le formulaire. Il serait aussi envisageable de rediriger le navigateur vers une adresse différente si toutes les informations ont été saisies correctement. Nous laisserons aux lecteurs la mise en place de ces fonctionnalités. +

+ + +Chaque validateur représente une règle de validation. Un champ de saisie unique peut être associé à un ou plusieurs validateurs. Les validateurs effectuent les vérifications aussi bien du côté client que du côté serveur. Côté client (navigateur), les validations sont effectuées grâce à du javascript, côté serveur, elles sont effectuées en PHP. Les validations côté client peuvent être désactivées tandis que celles côté serveur ne peuvent l'être. Ceci permet de s'assurer que les règles de validation sont toujours appliquées. + + +
\ No newline at end of file diff --git a/demos/blog-tutorial/protected/pages/Day1/fr/Setup.page b/demos/blog-tutorial/protected/pages/Day1/fr/Setup.page new file mode 100755 index 00000000..22a7891c --- /dev/null +++ b/demos/blog-tutorial/protected/pages/Day1/fr/Setup.page @@ -0,0 +1,161 @@ + + +

Installation

+ +

+Nous commencerons par la mise en place de la structure des dossiers et fichiers requis par la plupart des applications développées avec PRADO. Nous allons utiliser les outils en ligne de commande pour atteindre ce but. +

+ +

Nous partons du principe que le nom du dossier qui contiendra l'application est blog et que l'URL qui permet d'accéder à ce dossier est : http://hostname/blog/ (remplacer hostname par le nom de votre serveur). +

+ +

A l'intérieur du dossier blog, nous utilisons les outils en ligne de commande avec comme commande (remplacer path/to par le chemin d'installation du framework PRADO): +

+ +php path/to/prado-cli.php -c . + + +

+L'utilisation de cette commande permet de créer la structure de dossier et fichiers suivante: +

+ + + +

+Nous avons dorénavant, un squellette d'application PRADO accessible par l'URL http://hostname/blog/index.php et qui affiche une page contenant le message "Welcome to PRADO". +

+ +

+Il est de notre intérêt d'en apprendre plus à propos des dossiers et fichiers que nous venons de créer. +

+ +

Les fichiers initiaux

+ +

Le script principal de l'application

+ +

+Toutes les applications PRADO ont un point d'entrée, habituellement nommé index.php. Dans la plupart des cas, c'est le seul script qui est directement accessible par les utilisateurs. Cela réduit les risques que les utilisateurs puissent lancer des scripts serveur auquels ils ne devraient pas avoir accès. +

+ +

+Le but principal de ce script est d'initialiser l'environnement PRADO et de gérer toutes les requêtes utilisateurs. Ce script contient habituellement les commandes PHP suivantes, +

+ + +run(); +?> + + + +Le nom du script ne doit pas être obligatoirement index.php. Il peut porter n'importe quel nom à partir du moment ou le serveur peut l'interpréter comme étant un script PHP5. Par exemple, sur certains hébergements mutualisés, le script devra porter le nom index.php5, ce qui permettra au serveur Web de le traiter correctement. + + +

Le fichier de configuration de l'application

+

+Le fichier optionnel XML application.xml contient la configuration de l'application. Son but principal est de permettre de configurer l'application qui sera créée par le script principal. Par exemple, nous pouvons activer le système de log pour notre application par le biais du fichier de configuration. +

+ +

+Le fichier application.xml est pour le moment presque vide. De ce fait, nous pouvons le supprimer parce que l'application n'utilise pour le moment que des fonctionnalités de base. Au fur et à mesure que nous avancerons, nous ferons référence régulièrement au fichier application.xml et vous expliquerons comment configurer l'application. +

+ + +

La page d'accueil

+ +

+La page d'accueil Home.page (aussi dénommée page par défaut) est la seule page créée par les outils en ligne de commande de PRADO. C'est le contenu de ce fichier qui est affiché quand l'utilisateur navigue à l'adresse http://hostname/blog/index.php. +

+ +

+Le contenu du fichier Home.page respecte le format de template qui pour la plupart du temps est du code HTML agrémenté de quelques balises spécifiques à PRADO. Par exemple, dans Home.page nous voyons du code HTML pur : +

+ + + + + Welcome to PRADO + + +

Welcome to PRADO!

+ + +
+ + +

Les dossiers initiaux

+ +

Le dossier protected

+ +

+Le dossier protected, aussi connu sous le nom chemin de base de l'application, est le dossier racine qui contient les pages, les gabarits, les fichiers de configuration, les données, etc. Le nom protected indique que ce dossier doit être masqué des personnes qui consultent le site, ceci parce que les fichiers dans ce dossier contiennent la plupart du temps des données sensibles. +

+ +

+Les différents serveurs Web ont différents moyens de "protéger" un dossier. Pour Apache, le moyen le plus simple est de créer dans le dossier un fichier nommé .htaccess avec le contenu deny from all. +

+ + +

Les dossiers protected/runtime et assets

+ +

+Les dossiers protected/runtime et assets sont deux dossiers qui doivent avoir l'autorisation "en écriture" pour le serveur Web. Le dossier runtime contient des données sensibles (ie: fichier de configuration déjà analysé) générées à l'exécution de PRADO tandis que le dossier assets contient les ressources qui doivent être publiques (ie: les images, les fichiers javascript). +

+ + +Il n'y a aucun souci à supprimer les dossiers et les fichiers contenus dans protected/runtime et assets. Il est recommandé aux développeurs de nettoyer ces dossiers lors d'une mise à jour de PRADO. + + + +

Le dossier pages

+ +

+The pages directory is the root page directory holding all pages in a PRADO application. It bears an analogy to the htdocs directory for the Apache httpd Web server. +

+ +

+Nous avons déjà vu comment accéder la page d'accueil. Pour accéder à n'importe quelle page situé dans le dossier pages, il faut utiliser l'URL suivante http://hostname/blog/index.php?page=chemin.vers.NomdelaPage. En fonction de cette URL, PRADO recherche une page dénommée NomdelaPage dans le dossier pages/chemin/vers. L'URL que nous avons utilisée précédemment pour accéder à la page d'accueil correspond à http://hostname/blog/index.php?page=Home. + + +

Personnalisation

+ +

+Il est tout à fait possible de personnaliser le nom et l'emplacement des fichiers et dossiers décrit précédemment. +

+ +

+Par exemple, pour améliorer la sécurité, certains pourraient désirer déplacer la totalité du dossier protected à un emplacement inaccessible par le Web. Pour faire cela, utilisez la commande PHP suivante pour initialiser l'instance de l'application PRADO dans le script principal : +

+ + +$application = new TApplication( 'path/to/protected' ); + + +

+Pour changer l'emplacement du dossier racine des pages et le nom de la page d'accueil, il est possible de modifier le fichier de configuration application.xml de cette manière : +

+ + + + + + + + + + + +

+En avançant dans l'apprentissage de PRADO, vous verrez que PRADO est très souple et qu'il est possible de personnaliser la plupart des comportements de base. Nous décrirons d'autres techniques au fur et à mesure de ce tutoriel. +

+ +
\ No newline at end of file diff --git a/demos/blog-tutorial/protected/pages/Day1/fr/ShareLayout.page b/demos/blog-tutorial/protected/pages/Day1/fr/ShareLayout.page new file mode 100755 index 00000000..cefff770 --- /dev/null +++ b/demos/blog-tutorial/protected/pages/Day1/fr/ShareLayout.page @@ -0,0 +1,182 @@ + + +

Partager les modèles de gabarit

+ +

+Dans cette section, nous allons utiliser la fonctionnalité gabarit principal/contenu de PRADO pour partager une mise en page commune sur tout notre site. Les mises en page communes font référence aux parties qui sont identiques ou presque pour un ensemble de pages. Par exemple, dans notre outil de blog, toutes les pages partagent le même entête, pied de page et la même barre latérale contenant les liens. La solution la plus radicale est de répéter sur chaque page les parties communes. Par contre, cette approche est une source d'erreurs et difficile à maintenir. La fonctionnalité gabarit principal/contenu nous permets de traiter les parties communes comme un contrôle qui centralise la logique applicative et la présentation de chaque page. +

+ + +Il est aussi possible de partager les parties communes grâce à l'inclusion de gabarits, un peu comme l'inclusion de fichier php. L'inconvénient de l'inclusion de gabarits est que l'on ne peut pas partager la logique applicative. + + + +

Création du gabarit principal

+ +

+Nous allons maintenant créer le gabarit principal MainLayout qui représente les parties communes partagées par toutes nos pages. Le contrôle MainLayout est un contrôle de gabarit qui hérite de TTemplateControl. Il a besoin d'un fichier de gabarit MainLayout.tpl et d'un fichier de classe MainLayout.php situés dans le même dossier. Pour faciliter la maintenance, nous allons créer le nouveau dossier protected/layouts pour les accueillir. +

+ + + +

+Pour le moment, MainLayout contient seulement un entête simple et un pied de page, comme décrit ci-après. Plus tard, nous ajouterons une barre latérale. Les lecteurs sont encouragés à ajouter des fonctionnalités. +

+ + + +<com:THead /> + +<com:TForm> +
+ + + +
+<com:TContentPlaceHolder ID="Main" /> +
+ + + +
+</com:TForm> + + +
+ +

+Ci-dessus, le contenu du fichier de gabarit MainLayout.tpl. Trois nouvelles balises sont utilisées. +

+ + + + +

+Le fichier de classe MainLayout.php est très simple : +

+ + + + + + +L'extension des fichiers de gabarit est .page, tandis que pour les gabarits autres que les pages c'est .tpl. Ceci permet de différencier les pages des autres contrôles. Les deux utilisent la même syntaxe de gabarit. Pour les pages, le fichier de classe est optionnel (par défaut hérite de TPage), tandis que pour les contrôles, les fichiers de classes sont obligatoires. Comme pour Java, le nom de la classe doit être le même que le nom du fichier de classe. Faites attention à la casse sur les systèmes Linux/Unix. + + +

Utilisation du gabarit principal

+

+Pour utiliser notre gabarit principal nouvellement créé, nous allons modifier nos fichiers Home.page et Contact.page. En particulier, nous devons supprimer les entêtes et pied de page parce que le gabarit principal a la responsabilité de les afficher ; par ailleurs, nous devons indiquer aux deux pages que leur gabarit principal est MainLayout. +

+ +

+Ci-dessous, le contenu de Contact.page après les modifications : +

+ + +<%@ MasterClass="Application.layouts.MainLayout" Title="Mon blog - Contact" %> + +<com:TContent ID="Main"> + +

Contact

+

Veuillez remplir le formulaire suivant pour me laisser vos impressions au sujet de mon blog. Merci !

+ +...champs de saisie et validateurs pour le nom d'utilisateur... + +...champs de saisie et validateurs pour l'email... + +...champs de saisie et validateurs pour le commentaire... + +<com:TButton Text="Envoyer" OnClick="submitButtonClicked" /> + +</com:TContent> +
+ +

+Le contenu entre les balises <com:TContent> sera inséré dans l'emplacement réservé par <com:TContentPlaceHolder> dans le gabarit principal. +

+ + +Il est possible d'avoir plusieurs TContentPlaceHolder dans un gabarit principal et plusieurs TContent dans un fichier de contenu. Ils sont associés par leurs propriétés ID. Il est aussi possible de définir un contenu comme étant le gabarit principal d'un autre contenu, ceci en plaçant une balise TContentPlaceHolder à l'endroit désiré. Ceci est appelé gabarits principaux imbriqués + + +

+A côté de la balise <com:TContent>, nous avons vu une nouvelle balise <%@ %>, qui est dénommé une balise de contrôle de gabarit. Elle contient des paires nom-valeur utilisées pour initialiser les propriétés correspondantes du propriétaire de gabarit, dans notre cas, la page Contact. +

+ +

+En définissant la propriété MasterClass comme étant de type Application.layouts.MainLayout, nous avons indiqué à la page Contact d'utiliser MainLayout comme gabarit principal. Ici, nous avons utilisé un espace de noms pour nous référer à la classe MainLayout. +

+ + +Les espaces de noms sont largement utilisés en programmation PRADO. Ils sont utilisés conjointement avec les alias de chemins. PRADO définit deux alias de chemins: System fait référence au dossier framework de l'installation PRADO, et Application fait référence au dossier protected. +L'espace de noms Application.layouts.MainLayout peut ainsi être traduit par protected/layouts/MainLayout ce qui est précisément le nom du fichier (sans l'extension .php) de la classe MainLayout. + + + +

Autres possibilités pour spécifier le gabarit principal

+ +

+Il y a plusieurs alternatives pour spécifier le gabarit principal. +

+ +

+Vous pouvez définir le gabarit principal comme ci-dessous pour pouvoir en changer dynamiquement. +

+ + +MasterClass='Path.To.NewLayout'; + } + + // ... +} +?> + + +

+Ci-dessus, nous indiquons d'utiliser le gabarit principal MasterClass dans la méthode onPreInit() qui est héritée de TPage. Cette méthode est appelé par PRADO juste après que l'instance de la page soit créée. Nous pouvons ainsi déclarer au moment où la page est requise quel gabarit principal utiliser. Par exemple, quand la page est requise par un utilisateur enregistré, nous pouvons utiliser le gabarit A, et le gabarit B si l'utilisateur qui demande la page est un invité. +

+ +

+Nous pouvons aussi spécifier quel gabarit principal utiliser dans le fichier de configuration de l'application ou encore dans le fichier de configuration de la page. Ci-dessous, le fichier de configuration de l'application modifié pour notre blog. +

+ + + + + + + + + + + + + + +

+En faisant cela, nous évitons de définir le gabarit principal dans chaque page. Si nous décidons d'utiliser un autre gabarit principal, il nous suffit de changer le fichier de configuration de l'application. Pour cette raison, dans notre blog, nous utiliserons cette approche. +

+ + +Il y a un ordre qui permet de savoir quel fichier gabarit principal utiliser s'il est spécifié à plusieurs endroits. En particulier onPreInit() est prioritaire au fichier de configuration de la page qui est lui même prioritaire au fichier de configuration de l'application. Ainsi, si vous spécifiez MainLayout dans le fichier de configuration de l'application/page et que vous spécifiez SpecialLayout dans Contact.page, ce sera le dernier qui sera pris en compte. + + +
\ No newline at end of file diff --git a/demos/blog-tutorial/protected/pages/Day1/fr/directories.gif b/demos/blog-tutorial/protected/pages/Day1/fr/directories.gif new file mode 100755 index 00000000..884e15bc Binary files /dev/null and b/demos/blog-tutorial/protected/pages/Day1/fr/directories.gif differ diff --git a/demos/blog-tutorial/protected/pages/Day1/fr/directories2.gif b/demos/blog-tutorial/protected/pages/Day1/fr/directories2.gif new file mode 100755 index 00000000..edf264d0 Binary files /dev/null and b/demos/blog-tutorial/protected/pages/Day1/fr/directories2.gif differ diff --git a/demos/blog-tutorial/protected/pages/Day1/fr/directories3.gif b/demos/blog-tutorial/protected/pages/Day1/fr/directories3.gif new file mode 100755 index 00000000..3451935f Binary files /dev/null and b/demos/blog-tutorial/protected/pages/Day1/fr/directories3.gif differ diff --git a/demos/blog-tutorial/protected/pages/Day1/fr/output.gif b/demos/blog-tutorial/protected/pages/Day1/fr/output.gif new file mode 100755 index 00000000..9ad2bfb8 Binary files /dev/null and b/demos/blog-tutorial/protected/pages/Day1/fr/output.gif differ -- cgit v1.2.3