1Introduction 1Objectifs








télécharger 195.71 Kb.
titre1Introduction 1Objectifs
page2/9
date de publication02.04.2017
taille195.71 Kb.
typeDocumentos
ar.21-bal.com > loi > Documentos
1   2   3   4   5   6   7   8   9

2.2Framework de développement ou intégration d’outils PHP



Le choix des briques PHP sur lequel va s’appuyer la mise en œuvre d’une application est structurant en termes de coût de développement, de maintenance et d’évolutivité. C’est un choix stratégique pour le Conseil de l’Europe.
Trois types de cas peuvent se présenter, qui n’impliquent ni les mêmes réponses techniques, ni les mêmes normes de développement :


  • Cas 1 : Evolutions autour d’une application PHP existante au Conseil de l’Europe.

Les normes de développement à appliquer sont celles s’appliquant sur le projet et sur les outils PHP sur lesquels il s’appuie. Les normes présentement énoncées dans ce document sont à utiliser en complément et ne doivent êtres respectées que lorsqu’elles ne contredisent pas celles de l’application existante.

Quelques applications existantes : Métro (Mantis Bug Tracker), Tiki Wiki CMS Groupware, Uat (TestLink), …


  • Cas 2 : Développement d’une application basée sur un (ou plusieurs) outil(s) open source (CMS, Wiki, …).

Ce cas peut survenir lorsqu’un outil PHP existant est utilisé comme socle applicatif du fait d’une excellente couverture initiale des besoins.
Les normes ci-dessous s’appliquent tant qu’elles ne contredisent pas les normes de développement propre à cet outil PHP.




Ce choix d’outil PHP open source doit être fait en connaissance de cause, et doit être validé par le Conseil de l’Europe.




  • Cas 3 : Développement d’une application spécifique.

Ce type de développement sera basé sur un framework PHP accélérant le développement : Zend Framework. C’est le standard au Conseil de l’Europe.
Ces normes de développement sont prévues pour ce cas, et s’appliquent aux développements.
La version de Zend Framework à utiliser correspondra toujours à la dernière version stable.

2.3Environnement de développement


Nos plateformes de production utilisent la version stable de la distribution Linux Debian. Les tests ainsi que les compatibilités sont à assurer avec cette dernière version.
Cependant, le développement pourra être réalisé au besoin sur un environnement Windows, à condition que des tests soient effectués sur un environnement Linux Debian avant livraison.
En cas de développements visant à faire évoluer une application existante, le framework utilisé sera celui de l’application, sauf si la décision de migrer vers une version plus récente du produit a été prise par le Conseil de l’Europe.

3Règles de codage

3.1Règles générales


Les conventions de codage doivent suivre les recommandations ZEND. Celles-ci sont disponibles à l’adresse suivante : http://framework.zend.com/manual/fr/coding-standard.html.

3.2Formatage des fichiers PHP

3.2.1Nom de fichiers php



L’extension de tous les fichiers php doit toujours être « .php ».
Seuls les caractères alphanumériques et tirets « - » sont autorisés. Les espaces et les caractères spéciaux sont interdits. De plus les noms de fichiers doivent correspondre aux noms des classes comme décrit plus loin.

3.2.2Balise de démarcation du code PHP



Les codes PHP doivent commencer par une balise ouvrant PHP mais la balise fermante (« ?> ») ne doit jamais être utilisée :




...



La balise fermante n’est en effet pas requise par PHP et ne pas l’utiliser fait partie des recommandations Zend. Ne pas l'inclure permet de se prémunir les problèmes liés à l'injection accidentelle d'espaces blancs dans la sortie.
Les fichiers PHP doivent se limiter à du code PHP et ne pas inclure de blocs de code HTML. Le code HTML doit être placé dans des templates Smarty, le moteur de templating étant prévu pour cela.

3.2.3Indentation


Utilisez une indentation par espaces (et non par tabulations), comme préconisé par Zend. Chaque niveau d’indentation requière quatre espaces.

3.2.4Longueur maximum d'une ligne & saut de ligne


La longueur maximum de toute ligne de code PHP est de 120 caractères.

La terminaison de ligne à utiliser est la terminaison standard pour les fichiers textes UNIX. Les lignes doivent finir seulement avec un "linefeed" (LF).



N'utilisez pas de retour chariots (CR) comme le font les Macintosh ou de combinaison retour chariot/linefeed (CRLF) comme le font les PC sous Windows.


3.2.5Encodage







L’encodage des fichiers PHP, templates, scripts SQL et autres fichiers textes doit être un encodage UTF-8 (sans BOM).



1   2   3   4   5   6   7   8   9

similaire:

1Introduction 1Objectifs icon1Objectifs principaux du projet

1Introduction 1Objectifs icon1Introduction générale

1Introduction 1Objectifs icon1Introduction 1Objet du document

1Introduction 1Objectifs icon1introduction 1But du document

1Introduction 1Objectifs icon1Introduction au logiciel d'instrumentation Labview

1Introduction 1Objectifs icon1La visite scolaire à Paris 1Introduction

1Introduction 1Objectifs icon1Présentation du Groupe nrb 1Introduction
«mutualisée». C’est ainsi qu’en 1986 naît le gi (Groupement Informatique) sous l’égide de la smap (aujourd’hui Ethias) et de trois...








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com