Vos techniques pour le développement de sites en PHP

Bonsoir ,

Alors moi j'ai complètement restructuré le site sur lequel de bosse, voici ce que ça donne .

Architecture des dossiers

Code : Autre - Afficher / masquer les numéros de ligne
PS : J'en ai pompé pour faire ça .

Fonctionnement

J'utilise la méthode d'include dite « dangereuse », c'est la première fois que je l'utilise et c'est bien je trouve . Tout d'abord j'ai codé un système que je nomme « résolveur d'URL », celui-ci a pour tache de parser l'URL que le visiteur a soumise. Tout d'abord les URL se présente ainsi :



On envoie tout ça (sauf l'extension qui est retirée dans la règle de Rewrite) comme paramètre au script core.php via $_GET['url'], ensuite le script va parser ça en deux parties (au niveau du '~'). La première contient la page à appeler, et la seconde les arguments séparés par des '-'. Je dispose ensuite d'un Array qui fait la conversion de la page => script à exécuter ; par exemple 'accueil' va appeler le script 'mod/news/accueil.php', 'admin-news' => 'mod/admin/news.php'. Et les arguments sont contenus dans un array $_args.

Script d'exemple

Par exemple voici le script 'newTopic' du module 'forum'

Code : PHP - Afficher / masquer les numéros de ligne


Voilà .

Bonjour

J'ai presque tout lu les 3 pages en regardant vos codes et présentations, et j'ai presque mal au coeur. Je suis à me demander si ma façon de coder est la bonne car je veux refaire complètement mon site qui date d'un an et demi et ne me permet plus d'avancer.

Je remarque que beaucoup d'entre-vous avez utilisez le système de Templates et avez suivi un peu l'exemple des forums comme PhpBB. Par contre, pour un site comme le mien qui contient environ 100 pages et 50 gigs de contenu, je trouve le tout très lourd à monter, vous ne trouvez pas ?

Présentement, tout ce que je fais est un fichier index.php dans lequel j'appelle les pages. Chaque page possède les incluses pour l'entête, le menu et le bas de page. Je n'utilise aucune class car je n'ai toujours pas compris l'avantage même à lire tous les tutos.

Certains ont parlé de «cache». Faut-il recharger le cache à chaque fois que les données changent ?

Vous m'avez mêlé et royalement ! Mon site accueil environ 70000 visites par mois et a 6000 membres qui le visitent régulièrement. Que me suggérez-vous ? SVP, ne me demandez pas d'engager quelqu'un pour le faire

Merci!

Moi je te conseille d'utiliser Django : http://www.django-fr.org/ ou un autre Framework PHP si tu préfères.

Mais faire des sites sans utiliser un Méthode comme le MVC ou autre c'est vraiment s'arracher les cheveux pour rien.

En PHP on m'a dit beaucoup de bien de http://www.codeigniter.com/

Il va pas s'amuser à totu recoder, ca risque d'etre vite lourd. Et ton truc "a l'air" lourd Life2000 : Certes, pas forcemment besoin de classe (ou autre MVC, etc) [enfin ca dépend de la structure du site, etc], ce que tu fais peut très bien tenir la route.

Comme je l'ai dit, ca dépend vraiment de la structure du site, du contenu (dynamique ? "que" du statique ?), pour utiliser le cache, si tu sens que tu en a vraiment besoin pour de grosses requêtes et autres trucs du genre par exemple, ...

Bilbax > Joli l'arbre

Merci Natim pour les liens et infos, j'ai tout lu attentivement.

Pour répondre à tes question Talus, la majorité du site est dynamique. Une petite partie est statique et beaucoup moins visité. Mon principal problème est que j'ai monté ce site en 6 mois, seul, et que j'ai appris le PHP en même temps. Elle date de près de 2 ans maintenant. L'autre problème est que le site est de plus en plus populaire, ce qui crée un gros traffic et fait en sorte que les «bobos» comme des requêtes mal écrites commencent à sortirent. J'ai souvent entre 100 et 150 membres en ligne.

Mon intention est de refaire le site en entier en délaissant MyISAM pour InnoB, en espérant que cela aidera. De plus, je veux réduire la taille de mes tables, surtout celle des membres, pour améliorer les perfomances. Dans la dernière année, j'ai même changé de serveur pour aller vers un VPS, qui est beaucoup plus dispendieux qu'un hébergement standard.

J'aime beaucoup le principe du MVC (je crois que ce site l'utilise), mais j'ai l'impression que de longues heures de travail s'annoncent! Mon site comportent principalement des listes de membres que les visiteurs peuvent trier en utilisant des filtres. Exemple : voir uniquement les gars avec photo de 24 à 35 ans de la région de Montréal.

De plus, chaque membre peut avoir un album de photos, utilisez une messagerie privée qui se recharge dans un frame à toutes les 20 secondes, clavarder dans un chat JAVA (je loue les services d'une entreprise pour ça), etc. Vive le bénévolat!

Merci pour vos réponses rapides, c'est très apprécié. Bonne journée!

Une MVC, ca doit être réfléchis, ce que je te conseille c'est de réfléchir à la structuration de ton site (pas que l'arborescence mais aussi le système, la gestion de tes modules , pages ...).

C'est peut être long et dur à mettre en place mais une fois que le coeur du site est fait c'est déjà beaucoup plus simple, et puis si c'est pas trop mal structuré tu peut t'en resservir pour d'autres sites pas la suites.

Concernant les framework c'est bien, mais je pense que c'est mieux d'avoir son propre MVC, on connais bien le code et si il y a une modification à faire on s'y retrouve beaucoup mieux.

Je viens de lire 2-3 pages concernants les MVC et je commence déjà à m'arracher les cheveux. J'ai toujours eu tendances à mélanger tous les codes ensembles, plus simple à première vue pour mois. Finalement, je n'utilise présentement AUCUNE fonction. J'ai commencé à lire sur les classes et je crois que j'aurai besoin d'aspirine pour comprendre.

Il ne reste plus qu'à aller me promener sous un orage et attendre qu'un éclair de génie me frappe!!!

Le MVC doit passer par une étape d'adaptation du code il est vrai, mais au final, cela rend tout de même tout beaucoup plus clair.

Tout dépend de la facon dont on l'utilise... Par exemple, j'en utilise un qui s'approche du MVC (entièrement en OO) pour mon nouveau site, et je m'éclate bien

Surtout, ca reste bien clair et compréhensible... Ca reste très possible avec le OO PHP5

Salut,

Tout le monde parle de MVC, mais personne n'utilise d'architecture en "postback" type Prado ?


Tracker.

J'ai lu ce topic qui m'a l'air très intéressant

déjà je savais pas qu'on pourvait faire LIMIT $x OFFSET $y

sinon plusieurs questions me viennent à l'esprit :






Merci beaucoup

1) PHP. Soit aucuns, les framework, ca pue §§
2) Ben si tu veux, tu te retrouve pas avec des fonctions comme justement "inserer(table, titre)", "recuperer(ressource)", etc, mais avec un truc plus clair dans ton code sourcE. Surtout, tu peux avoir des éléments interessants (via l'héritage de class, activation ou non d'options, etc).
3) Ca dépend des CMS...

Encore cet argument pourri de la soit-disant clarté de l'orienté objet ?

Waow quel topic hyper intéressant

Que de mots nouveaux :P CMS, class ... :P

Je sens que je vais devoir lire un petit peu

Vous connaissez des adresses de sites qui expliquent bien tout ces concepts ?

Merci

j'aimerai des réponses clair pas dire que ca pue ou quoi...

Citation : Shepard

Désolé de poser une question sur le premier post qui date un peu

Je ne comprend pas pourquoi il existe 3 fichiers différent pour : modifier/ajouter et supprimer une news.

Je comprend pas vraiment l'utilité :S Dans le ficher del_news.php par exemple y a quoi ?

Code : PHP - Afficher / masquer les numéros de ligne

Je vois pas très bien l'intérêt de créer un fichier juste pour 3 lignes :S

Ou alors j'ai rien compris C'est très possible

Salut,

Quelle différence pour toi de créer un ou dix fichiers ?


Tracker.

Euh ...

Bin personnelement je préfere avoir un fichier

gerer_news.php

que 16847 fichiers

Supprimer_news.php
Ajouter_news.php
Modifier_news.php
Move_news_haut.php
Move_news_bas.php
Afficher_news_par_id.php
Afficher_news_par_timestamp.php
Afficher_news_par_pseudo.php
Afficher_news_par_contenu.php

etc ... etc ...

Et puis je trouve ça assez lourd les redirection :S
ça ne ralenti pas le site ?

Citation : balzard

Je vois, sur tous les posts où tu participes, que finalement ton but est de justifier à tout prix ta façon de coder ou concevoir un "site", pour finalement ne rien changer, libre à toi (je sais c'est chiant de se former). Sache simplement qu'il existe des tas de philos/outils de développement web s'appuyant le plus généralement sur des "frameworks" ou "applications dédiées" dont les bugs sont connus et progressivement corrigés (et pas par toi), et que beaucoup de boite utilisent pour produire plus efficacement des solutions professionnelles.

Si l'objectif que tu t'es donné consiste à faire et refaire 50 sites contenant de livre d'or de mattéo continue si ta lancée, mais si tu avais à monter un site/appli dont le modèle contenait des dixaines tables et dont l'ergonomie, la sécurité, etc... devait irréprochable, tu serais sans doute dans une profonde panade... (rien qu'au niveau délai de réalisation)


Tracker.

--- Je vois, sur tous les posts où tu participes, que finalement ton but est de justifier à tout prix ta façon de coder ou concevoir un "site" ---

A mais absolument pas, je me balade énormément sur le forum php afin d'améliorer ma façon de créer des sites car je sais que ma méthode est un peu barbare, je me renseigne sur tout ce qui existe et je pose des questions ...

Je ne suis pas fermé ou têtu ... J'essaie simplement de comprendre les pour et les contres de chaque "philos/outils de développement web" comme tu les appelles si bien

Tes 16847 fichiers, c'est du flan.
Séparer en fichier ne veut pas dire qu'on va créer 1001 fichiers, séparer en fichier veut dire 1 fichier = 1 action.
Monter ou descendre une news, c'est une action paramétrable, donc un fichier. Afficher les news ordonnées par id/date/etc., c'est une action paramétrable, donc un fichier.

Les atouts de cette séparations sont multiples. D'abord, il y a la facilité de maintenance et la clarté du code. Comme chaque action est à part, il n'y a pas de dépendances, on peut donc modifier une action particulière très facilement sans se soucier des dépendances puisqu'il n'y en a pas.
Aussi, c'est très évolutif et modulable. Si le créateur de l'application met à jour une ou deux actions, plus besoin de télécharger un gros fichier de 16847 lignes, suffit de télécharger un ou deux petits fichiers (qui peuvent quand même être gros, évidemment).
Ca permet aussi de répartir aisément la tâche dans un groupe de développeurs. Avec un seul fichier, tout le monde bossera sur le même fichier et ça sera un enfer, toujours à aller chercher le dernier fichier, toujours devoir vérifier qu'il n'y a pas eu de modif, que ce qu'on va modifier ne va pas faire planter tout le reste, etc.
Avec une action par fichier, tu dis "toi tu fais telle et telle action, toi ça et ça, etc." et comme ça personne ne se marche dessus.
Bien sûr derrière chacune de ces fichiers il y aura quelques bases communes, par exemple la gestion de la base de données, des permissions des utilisateurs, etc. seront uniques et communs à toutes les actions, mais comme on aura prit le soin de bien documenter cette base commune, de bien donner l'interface, etc. tout le monde saura l'utiliser comme il faut.
On peut aussi citer l'avantage du débuggage, si ton application merdouille quelques part, suffit de regarder le fichier lié à l'action qui foire, ainsi on se retrouve à chercher un bug dans un code réduit au lieu de le chercher dans une jungle ..

Il y a beaucoup d'avantages à éclater une application en plusieurs éléments indépendant liés à un socle commun. Surtout quand on veut ajouter des éléments, avec une telle architecture ça consiste simplement à suivre une interface, taper le code de l'élément et le mettre dans les dossiers.
Avec une architecture gros pâté, faudrait modifier le code pré-existant, faire gaffe aux dépendances, etc.

Apperement j'en ai choqué plus d'un Désolé :P

Les 16847 fichiers s'était une ironique Ainsi que l'affichage selon chaque type.

Je viens de lire un article sur le MCV «Modèle, Vue, Contrôleur » et je comprend maintenant beaucoup mieux les nombreux avantages de ce genre de "construction".

Merci Et encore désolé de vous avoir choqué

Je pense qu'il serait cool de développer un peu ce topic, afin de trouver une ou plusieurs structure pour son site, pour partir sur de bonnes bases

Templates ou pas ?
1 fichier par action ou pas ?
quelle méthode pour le traitement des formulaires ? tout sur une page, 2 pages ? gestions des erreurs ? ré-affichage des champs pas rempli ?

Il n'y a pas de réponse universelle sauf pour la première question, et pour cause, dès qu'on fait du PHP, on utilise un moteur de template, après qu'on utilise une sur-couche supplémentaire ou pas, osef.

Citation : ZyggiX

Une idée?

Essaye Jelix comme Framwork, sorti il ya pas longtemps, il à l'air pas mal.

La différence entre une fonction et class, je dirais que c'est plus une fonction de goût

Les modules des CMS sont stockés dans une bdd, ce qui devien ttrès facile de les activer ou désactiver.

je n'ai pas tout lu mais qu'est ce qu'un framework ?
a quoi sert-il?
merci

Citation : reboss

Salut,

Un framework est un "environnement de développement". En clair, c'est un gros ensemble de fonctions et de classes préfabriquées qui te permettent de ne pas tout réinventer toi-même. La plus part du temps, les fonctions de base gèrent la structure générale du site (rediriger les url vers les pages concernées, gérer les erreurs SQL, 404 etc.). Après, tu as souvent des helpers qui te permettent de gérer, par exemple, les url plus facilement via des fonctions préfabriquées.

En gros, ça te permet de rester constant dans ton développement, ça te donne quelque chose de compact, de portable (si tu changes de SGBDD par exemple), de structuré, etc..

Pour plus d'infos : wikipédia

Pour ma part, j'utilise le framework PHP CodeIgniter
Ses avantages :

• Fonctionne avec PHP4 ET PHP5
• Invisible pour l'utilisateur du site
• Facilite la manutention grâce au modèle MVC (Model, View, Controller)
• Pas besoin d'utiliser de console
• N'est pas restrictif quant au langage à utiliser (tu peux tout coder en PHP standard si ça te chante)
• Très, très, mais alors très bien documenté !! (en anglais malheureusement)
• Le Core est traductible en de nombreuses langues (messages d'erreur, etc.)
• J'en oublie encore sûrement plein

Le site officiel : Codeigniter.com
Un article sur mon blog : ici

A+

Citation : Nesswaw

En effet, essayer de trouver une structure de site serait interessant, mais en général, les gens aiment développé leur site a leur maniere. Enfin on pourrai quand même essayer de faire quelque chose et le proposer par la suite pour voir ce que les gens en pense ou voir si il y a des choses a améliorer.

1 fichier par action : oui , j'utilise cette façon de faire je la trouve très bien, c'est beaucoup plus pratique pour la maintenance et pour faire evoluer le site.

Ensuite, j'utilise une class SQL, et je sépare les requêtes de mon code.

Templates : Je ne sais pas encore ... Je me pose moi même cette question.

Gestion des erreurs: Oui, pour PHP et SQL, peut etre aussi un système pour les liens morts, faut voir si c'est possible a développer.

Géré les valeurs des meta-tags (keywords et description) en fonction de la page appelé.

Appelé les scripts Js et les feuilles de style en fonction des pages demandé.

Utilisation d'un systèmes d'includes ? Moi j'en utilise 1 faut voir si c'est une bonne idée ou pas.

Apres faut voir si il n'y a pas autre chose a faire.

Citation : metalking

En passant, tu as un joli icone w3c mais dès la première page : http://validator.w3.org/check?uri=http%3A%2F%2Fwww.metalking.net%2Fblog%2Findex.php%2F2007%2F08%2F31%2F21-bien-commencer-avec-codeigniter

Dommage

Tu vois bien que c'est du Dot Clear...