Moi je tourne en utf-8 pour mes pages et pour mySQL, pour le framework je ne sais pas par contre... :$

Symfony comme framework PHP et UTF-8 pour l'encodage.

Surtout bien choisir son encodage dès le début et s'y tenir, parce que c'est très très chiant de devoir convertir ses données après coup.

J'ajouterai qu'au boulot on utilise tous l'UTF-8 et qu'on à jamais de problème d'encodage

Moi c'est choisi depuis un moment : UTF-8 c'est plus simple a écrire que ISO-8859-1.

> Moi c'est choisi depuis un moment : UTF-8 c'est plus simple a écrire que ISO-8859-1.

Comment voulez vous que Nicolas ne ressortent pas "un codeur est feignant" apres ca? :p

Encodage :

-> Fichiers PHP : utf8 sans BOM
-> BDD : interclassement de la base en utf8_unicode_ci ou utf8_general_ci
-> Encodage html : utf8 dans les metas et forçage avec la fonction header() de PHP

Framework :

Personnellement, tu peux faire du MVC avec PHP sans framework. Il suffit de savoir structurer son application. MVC ne veut pas dire scripts PHP d'un côté et templates de l'autre.

Je t'invite à lire la discussion suivante que j'ai eu avec Frédéric Bouchery et Nicolas Roudaire sur PHPScripts-fr :

www.phpscripts-fr.net/for...

Sinon, j'ai appris que le Zend Framework était sympa à utiliser. Le fait qu'il soit en constante évolution est un plus aussi car il va subir pas mal d'ajouts et de modifications.

++

L'unicode est l'avenir, ISO appartient au passé.
Nous sommes en période de transition alors les 2 restes valides, mais un jour ce ne sera plus le cas. Reste à savoir si les développements actuels seront encore en fonctionnement lorsque l'unicode aura supplanté l'iso si tu ne veux pas avoir à tout modifier.

Pour le framework, s'il possible de faire une émulation de MVC avec du PHP, c'est un peu aberrant en soit.
C'est un peu la même chose avec le pure objet. Si PHP le permet, il n'est guère judicieux d'utiliser cette méthode en dehors du cadre didactique.

1° Ça plombe les perf d'un serveur en charge.
2° Cela revient à se priver volontairement de nombreuses fonctionnalités qui ont fait la réputation que connait PHP aujourd'hui.
3° La programmation objet est plus éloigné de la pensée humaine (plus procécurale) ce qui augmente la potentialité de présence de bug. Cela est généralement compensé par les langages adapté au pure objet, dans le cas de PHP, c'est prendre gratuitement un risque plus grand de voir la qualité du code dégradée.
4° PHP dispose en outre de nombreuses fonctions permettant de réutiliser le code. C'est un des principaux arguments et point fort de l'objet qui trouve là une alternative bien plus riche.
Je ne dis qu'il ne faut pas utiliser d'objet en PHP, mais que le pure objet n'est ni utilise ni nécessaire dans PHP qui nous permet d'utiliser le meilleur des 2 mondes (Objet et Procédural).

Pour ce qui est des design pattern, PHP est déjà en lui-même, un moteur de template, à l'origine il s'agissait d'un CGI écrit en C. PHP a été créé pour pouvoir intégrer dans une page HTML des éléments actifs. Vouloir de nouveau séparer le code de la présentation revient à faire marche arrière. Non pas une marche n'arrière négative, je m'explique. Cela est parfois utile, mais utiliser PHP (qui est là pour intégrer des éléments actifs à une page) pour créer de nouveau un langage ou système pour l'en séparer puis les rassembler ensuite. Ça revient à utiliser PHP pour faire ce qu'il est censé éviter.

Pour formaliser cela : soit A, la séparation du code et de la présentation, soit B leur regroupement.
A > B > A
On a 2 étape inutile, autant ne pas utiliser PHP pour regrouper le code de et la présentation si c'est pour ensuite les séparer.

C'est un peu complexe, je pourrais fournir plus de détail sur demande.

A noter dans ton choix: Jelix possède un support en français, et même si tu maîtrises parfaitement l'anglais, je pense que c'est un argument non négligeable!

En CMF il y a ModX qui est apparemment génial. Comme je ne suis pas très engagé la dedans, je ne peux pas donner un avis objectif mais je dois dire qu'on m'en a dit beaucoup de bien.


bonne chance

en espérant aider

Bon bah comme tu le sais je suis passé à Symfony il y'a peu. Je relance le sujet pour dire qu'en framework, Symfony est parfait.

* Points forts (dans l'ordre qu'ils apparaissent dans ma tête ^^) :

- Full object et templates traditionnels (= sans surcouche inutile via un moteur de templates)
- Installation en lignes de commande via PEAR ou SVN (ou pas via la sandbox).
- Gère l'environnement de développement et de production.
- Excellente console de debbugging.
- Scaffolding = génération des fichiers à la volée
- Abstraction de bases de données
- Object Mapping et Mapping relationnel sur la BDD
- Grosse documentation et tutoriels
- Grosse communauté de développeurs
- Tout un tas de plug-ins téléchargeables et installables facilement
- OpenSource avec la licence la plus permissive possible
- Portabilité de certaines classes du ZF sur Symfony
- Génération automatique de backoffice
- Adapté pour le RAD et le team project.
- Entièrement configurable via les fichiers YAML
- Gère l'internationalisation
- Validation automatique des formulaires par écriture de règles dans les fichiers YAML
- Robuste et sécurité poussée
- Génération automatique des méthodes CRUD (Create, Update, Delete, Retrieve) pour chaque classe d'objet.
- ...

Les atouts sont nombreux et c'est pourquoi j'ai choisi ce frameworks. Passons aux points faibles :

* Points faibles :

- Un seul selon moi : il faut quelques heures d'entraînement sur les tutoriels pour en comprendre le fonctionnement global.

Une fois celui ci maîtrisé (grâce notamment au tutoriel Askeet présent sur le site), le développement devient un jeu d'enfants et même très plaisant. Nous n'avons plus à écrire un tas de lignes de codes car le framework en génère la plupart.

La force et la puissance de Symfony resident dans les atouts explicités ci-dessus. C'est pourquoi je vous conseille personnellement de vous plonger dedans. C'est un vrai régal à utiliser

++

Hugo.