j’include un open.inc, qui va me lancer ma page, inclure toutes les classes, les fonctions et tout le bordel, ainsi que l’header et la leftbar de ma page. Ce fichier se termine par l’ouverture de ma div de contenu.
Là je place mon contenu
Puis close.inc, qui ferme la div, inclue le footer et ferme tout correctement.
Pour les adresses relatives, j’utilise une fonction root(); qui va me retourner le nombre de “…/” pour retourner au root de mon site
ex pour une image:
pour les adresses absolues, j’ai une constante define PATHTOROOT.
ex d’inclusion d’un block:
ça marche tout à peu près bien. Mais je me demande s’il n’y a pas mieux, plus simple, plus mieux quoi.
[quote=“xsybus, post:1, topic: 47306”]<img src="<?php echo root(); ?>Images/Ressources/test.png" />[/quote]Ça serait pas plus simple de mettre <img src="/Images/Ressources/test.png" /> ?
Comment tu définis PATHTOROOT ? Au cas où, peut être que tu ne connais pas dirname(FILE). Ça permet d’avoir le chemin absolu du fichier qui appelle cette fonction. Par exemple avec Dotclear 2 ça définit la racine de Dotclear ainsi :define('DC_ROOT',dirname(__FILE__).'/..');
mais avec ça on se retrouve au root du serveur. Si mon site est dans un sous dossier ça pose problème… comme ça arrive souvent (tout le temps?) chez des host du type 1&1. A moins qu’il y’ai un truc que j’oublie…
oui voila, c’est à peu près ça sauf que j’ai une fonctionnalité d’installation de mon truc, et qui défini Pathtoroot dans mon fichier open.php, qui est ensuite inclus dans toutes mes pages (qui sont dans différents niveaux de sous-dossier).
déja testé rapidement, (trop certainement). Je trouve ça un peut trop complet aussi. Et de toute façon je veux faire mon propre truc à moi
comme petit framework mvc gnagna tu peux regarder du côté de code igniter qui est un petit framework mais qui fourni pas mal de choses, ça peut-être utile.
D’un autre côté, je trouve que tu ne sépare pas assez le fond et la forme, le coup du “bon cet include ouvre un div” …
Si je peux me permettre un petit commentaire : laisse l’extension php à tous les fichiers qui contiennent du code php (par exemple open.inc et close.inc que tu cites dans ton premier post). Préfère close.inc.php à close.inc.
Si ton serveur n’est pas configuré pour interpréter via php les fichiers d’extension .inc, ils seront affichées en clair chez le client s’ils sont appelés directement (sans passer par un include). Et c’est potentiellement une ouverture dans ton serveur (accès aux sources, à d’éventuels mots de passe, a des failles dans ton code, etc).
En ce qui concerne ton organisation, j’ai longtemps pratiqué la même (enfin dans le même genre) (j’ai changé aujourd’hui ayant développé à force un framework personnel). Il y a une chose que j’ai vite pris l’habitude de faire : la racine du site je la code en dur dans un fichier de conf. Trop eu de surprises sur une mauvaise interprétation du chemin via les fonction prédéfinies de PHP. Si tu changes la racine du site c’est une ligne à modifier dans la conf.
Pas une mauvaise idee, mais ca depend du serveur, en IIS 6+ par exemple, les fichiers avec un MIME type non enregistré ne sont pas servi justement pour eviter ce genre d’ennuis.
Oui c’est pas forcément un risque, mais bon, ça coute pas grand chose de coller directement la bonne extension plutôt que de se taper le renommage de tous les fichiers et des appels le jour où le script et déménagé sur un serveur différent.
D’autant que si on est amené à travailler avec d’autres langages que le PHP (genre javascript, xml, etc) c’est pas plus mal de savoir directement qui est écrit en quoi (pas toujours le plus évident de segmenter en fonction du langage, il peut arriver que des fichiers JS et PHP doivent cohabiter).
Bref, plus simplement : ça n’a aucun intérêt de nommer ses fichiers .inc, mais alors strictement aucun. Par contre ça peut éventuellement représenter des risques selon l’environnement. A toi de choisir. :crying:
Le pire qu’on puisse croiser c’est les fichier conf.inc. C’est un appel au hack.
De rien. Après si tu veux aller vers une organisation plus efficace (Selon moi. Y a moyen de faire efficace sans, question de philosophie), essaie de réflechir objet et dis-toi qu’une page est un objet, que toutes les pages d’un site ont des caractéristiques communes (ce que tu mets dans open.inc). Partant de ce principe, tu arrives rapidement à un système d’héritage qui te permet de créer une page web en quelques clics et surtout d’apporter des modifications et corrections de manière propre et sécurisée. En allant plus loin, tu te fais même un mini-framework qui te permet de regrouper les caractéristiques communes à tous les sites web (entêtes, corps de page, pied de page, etc) et donc tu facilites tes futurs développements.
Le gros plus de cette solution c’est que si une page devait diverger, tu override seulement la méthode concernée, alors qu’avec ta solution, il te faut obligatoirement créer un autre fichier open.inc et là c’est le début des emmerdes. :crying:
Ca nécessite de tourner sur du PHP5 pour être vraiment efficace (gestion des exceptions, des accesseurs, etc). L’objet et PHP4 je m’y suis jamais risqué.
l’idée d’un objet page m’étais venu ya quelques mois, deux méthodes principales, ouverture(), fermeture()… mais c’est vrai qu’avec l’héritage y’a moyen d’aller encore plus loin… Il faudra que je me penche là dessus.
Je tourne en PHP5, et j’utilise l’objet donc c’est bon.
En fait je suis au fur et à mesure en train de me créer mon framework (même si c’est un bien grand mot) je trouve ça plus intéressant que d’en utiliser un déja tout fait.
Il faudra aussi que je me penche sur la gestion des exceptions, histoire d’avoir un truc homogène aussi. Trop de trucs à faire pfiouuuh!
Merci en tout cas!
Je ne connais pas vraiment PHP, mais le fait d’ouvrir des balises dans un fichier et de les fermer dans un autre est une grosse source d’erreurs ! Il vaut mieux utiliser un système d’encapsulation :
Pour l’objet page, c’est pas tant ouverture(), fermeture() qu’il faut implémenter. Réfléchis plutôt à ce qu’il y a de commun dans toute page web :
(Ca peut varier mais c’est en gros la structure habituelle)
Une entête
Un corps de page
Un pied de page
T’as déjà là 3 méthodes définies par la classe mère. De simple méthode d’affichage, mais c’est déjà ça.
Mais on peut aller plus loin :
Toute page web peut potentiellement être la page de destination d’un envoi de formulaire, donc un méthode de gestion des POST. Bien entendu elle fera peut de choses dans la classe mère, mais tu pourrais par exemple y implémenter des méthodes de vérification généralistes, ou tout simplement vérifier que le POST existe et agir en fonction. Par exemple dans mon framework, j’ai implémenté dès la classe mère une méthode qui vérifie s’il y a des valeurs POST, qui lance une méthode de process de ces valeurs puis une méthode qui redirige sur la page courante. Comme ça plus de problème de double envoi d’un même formulaire, et plus besoin de me préoccuper de cette problématique par la suite. L’avantage de l’objet ici c’est que les classes filles implémentent la méthode de process comme elle le souhaite, alors qu’avec une structure non objet ce serait plus délicat à gérer.
A toi de voir, il y a pas mal de possibilités de factorisation. Le tout c’est de ne pas se bloquer, toujours bien réflechir et faire la part en factoriser du code et se fermer des possibilités par la suite, la redéfinition de méthodes n’est pas une panacée non plus. :crying:
Surtout pas! c’est toujours bon d’avoir le retour de quelqu’un qui à déjà fait tout ça!
je vois bien donc:
-header(), qui charge toutes les variables nécessaires au bon fonctionnement du site, qui inclue les classes, fonctions… et qui charge le header html du site. Gestion du titre de la page en paramètre par exemple…
-menu(), qui charge le menu, avec éventuellement en paramètre l’endroit où l’on veut le mettre…
-footer(), qui charge le footer de la page et la ferme.
Par contre, pour le corps j’ai du mal à imaginer à quoi ça pourrai ressembler… à la limite, deux méthodes, une de début et une de fin. Mais en une seule méthode… Tu lui passe le contenu de la page en paramètre?
Arf désolé, pour je ne sais quelle raison, j’ai pas été averti d’une réponse à ce thread.
Pour te donner une piste un peu plus détaillée, voilà comment je fonctionne (c’est pas forcément la meilleure solution pour peu qu’elle existe, mais c’est une solution qui me plaît). :crying:
J’ai un « Manager de site ». En gros une classe, appelons-la site.class.php, qui se charge de gérer le site comme son nom l’indique. Il s’agit d’un singleton, bien qu’il n’y ai aucune raison qu’il soit appelé deux fois (donc par sécurité simplement). Il possède quelques méthodes, comme par exemple la méthode qui permet de déterminer si la page demandée est une page valide ou pas, il initialise les variables globales à tout le site, la session, etc. Bref tout ce qui est global ou inhérent à un site web. C’est aussi lui qui se charge de charger les librairies liées à la page demandée (bon là on entre dans le système d’organisation de mon framework et c’est pas forcément pertinent).
La classe site, grosso modo, a le rôle de charger la page, d’instancier donc la classe page demandée. Pour cela il faut des classes page. Elles sont organisées de cette manière :
Une classe abstraite pageBase.class.php qui définit le fonctionnement général d’une page. Il y a donc principalement des méthodes abstraites dans cette classe car si le fonctionnement d’une page web est sensiblement toujours le même, son implémentation varie systématiquement. Mais il y a certaines choses qu’on peut généraliser :
le header HTML du site par exemple (je le fait dépendre de certains attributs pour affiner un peu, attributs redéfinis dans chaque page dérivée).
Le footer
Elle déclare également si il y a des données POST à gérer il faut rediriger sur la page courante après les avoir gérer, ça supprime le problème des retour en arrière qui génèrent une alerte niveau browser et le risque de double post.
J’ai aussi une méthode qui appelle le header() (non abstraite), le footer() (non abstraite) et le corps() (abstraite). Et là je pense répondre à ta question.
Différents petits trucs.
Le reste est géré au niveau de chaque classe page fille. Basiquement, pour créer une page toute bête, il suffit de définir la méthode corps() et hop on a une belle page HTML qui s’affiche avec tout le bouzin qui est géré (session, globales, etc). Après tu affines et tu ajoutes les outiles dont tu as besoin.
Merci pour toutes ces précisions, c’est bien intéressant, c’est trop tard pour mon projet actuel, qui est déjà bien attaqué, mais je verrai ça en détails pour la suite.
ça fait partie des trucs qu’on trouve rarement dans les livres et sur internet, mais qui permet d’optimiser et de gagner un temps fou sur le développement d’un site, sans passer par un cms.
