APPLICATION AVEC SYMFONY 1.4
Bonjour à tous, je suis une étudiante en informatique, jai déjà programmé avec PHP, je veut faire une application web où le front office avec PHP 5 orienté objet et le back office avec symfony 1.4.
Est-ce que cest possible ensuite de relie les deux parties ?
Merci
Réponses apportées à cette discussion
Salut,
qu'est-ce qui t'empêcherait d'utiliser symfony tant pour le front office que pour le back office ? C'est aussi une question d'architecture logicielle à prendre en compte pour la cohérence globale de l'application. Songe aussi à la maintenance à long terme.
Bien sur que tu pourrais à peu près tout imaginer, mais il ne me paraitrait pas inutile de conserver un coté rationnel ... Et j'ajoute que symfony est en PHP5 et codé en orienté objet, donc le lien ne devrait pas poser de difficultés particulières
Bonjour ,
Merci pour la réponse, mon but de séparer le front office en PHP5 et le back office en symfony, cest que je veux que la partie back office soit connue seulement par l'administrateur de site.
Salut,
je crois qu'une petite explication de texte s'impose :)
Lorsque tu construis une application web (et note que j'emploie à dessein le terme « d' application » au lieu de « site »), tu peux avoir deux parties, l'une publique et librement accessible par tout le monde, la seconde à accès restreint pour l'administration. Avec un framework comme Symfonym on utilisera pour ça le package de gestion des ACL (Access Control Layer) pour déterminer quel degré d'habilitation est requis pour telle ou telle page de l'application. Ça peut aussi bien être une page publique qu'une page à accès privé, les droits ne seront tout simplement pas les mêmes.
Donc, telle que tu as formulé ton idée, on pourrait penser que tu voudrais monter la partie publique en procédural, ce qui n'aurait aucun intérêt, mais même en admettant que tu le montes en orienté objet, pourquoi ne pas utiliser Symfony pour la partie publique au même titre que pour le back office ? Ça te donnerait une cohérence bien plus grande au niveau de l'architecture globale de l'application, et puis il ne faut pas oublier non plus un point important : le contenu de la partie publique sera géré dans la partie privée : mais au final, tout ça se connectera sur la même base : tu vas donc devoir développer pour le back office certains éléments de code qui seront utiles pour le front.
Enfin quoi qu'il en soit, quelle que soit la manière dont tu construiras le front office, le lien sera toujours possible, mais tu te faciliteras la vie en utilisant Symfony au même titre que tu l'utiliseras pour le back office sans que ça gène l'accès publis au front office.
Pour rebondir sur l'explication de texte entamée plus haut , je dirais ceci : Symfony, tout comme le Zend Framework, Cake, Hoa, Jelix et n'importe quel autre framework, c'est quoi au fond ? Un cadre de travail avec une partie servant essentiellement à gérer les problèmes d'architecture logicielle (quels fichiers, où, quel format, etc..) et des collections de packages pour les traitement génériques (accès aux données, formulaires, ACL, génération de PDF ou de document bureautique ou textes, gestion de flux de données, etc, etc.. on pourrait en citer jusqu'à demain matin) : partant de là, il n'y a aucune raison de limiter l'utilisation du framework à une partie ou une autre d'une même application, ce serait même probablement contre-productif. L'intérêt du framework, c'est que ça impose une méthode de travail uniforme pour l'ensemble de l'application. Pour la maintenance à long terme, c'est un très gros avantage. Si tu écates le frasmework pour le front office, ça risque de créer des surprises au niveau maintenance.