Separer le code PHP du reste

CrazyCat

21/07/2005 à 11:31

Jean-Francois Ortolo wrote:

Bonjour Monsieur

Tutoyons nous, ce sera plus convivial :)

Oui, bien que pour les javascripts, il suffit de la vraie balise html:
<script language="javascript" src="./repertoire/fichier.js"></script>
Pour passer des variables PHP à des scripts JavaScript, il me semble

qu'il faut nécéssairement passer par un script en PHP contenant des
instruction echo ( ou print ), contenant le code HTML appelant le script
JS adéquat.

En effet, mais il vaut mieux le faire à bon escient.
Pour ma part, et même si je suis l'avis auquel je me réfère, j'ai
tendance à éviter l'inclusion de variables PHP dans le JS.
Sachant que ces variables sont toujours pour de l'initialisation, autant
créer une fonction JS à laquelle on passe les variables JS au chargement
de la page (<body onload="initialyze(.....);">)

Je disais: "Dans des pages HTML".

Oui, mais dans le post initial, on parlait de séparer le PHP, le HTML et
le JS :)

Il est vrai que l'on peut toujours se ramener à une racine
d'arborescence qui soit un script PHP, mais n'oublions pas que la page
d'accueil, elle, est le plus souvent une page HTML: index.html

Ah? rappelons tout de même que 99.9% des serveurs acceptant le php
prennent comme page d'index les .htm, .html et .php

[snip]

Il me semble toujours plus simple d'avoir une page de type "ossature"
qui va appeler différentes parties, mais tout dépend du site.
S'il contient des pages complètement différentes, aucun intérêt, c'est
clair. Mais si le site contient 2 types de pages (habituellement un
accueil et le reste), autant avoir "le reste" sous forme modularisée.

D'un autre coté, c'est un avis qui vaut ce qu'il vaut et n'engage que
moi, mais j'ai eu l'habitude de faire des projets dans lesquels les
pages avaient tendance à s'ajouter au fur et à mesure... c'est tout de
même plus simple de copier l'ossature et d'ajouter un module dans les
possibilités d'includes :)

@+
--
Découvrez Original War: http://www.original-war.org
Humour: http://www.chatfou.com
Tchattez en liberté: http://www.crazy-irc.net

Jean-Francois Ortolo wrote:

Bonjour Monsieur

Tutoyons nous, ce sera plus convivial :)

Oui, bien que pour les javascripts, il suffit de la vraie balise html:
<script language="javascript" src="./repertoire/fichier.js"></script>
Pour passer des variables PHP à des scripts JavaScript, il me semble

qu'il faut nécéssairement passer par un script en PHP contenant des
instruction echo ( ou print ), contenant le code HTML appelant le script
JS adéquat.

En effet, mais il vaut mieux le faire à bon escient.
Pour ma part, et même si je suis l'avis auquel je me réfère, j'ai
tendance à éviter l'inclusion de variables PHP dans le JS.
Sachant que ces variables sont toujours pour de l'initialisation, autant
créer une fonction JS à laquelle on passe les variables JS au chargement
de la page (<body onload="initialyze(.....);">)

Je disais: "Dans des pages HTML".

Oui, mais dans le post initial, on parlait de séparer le PHP, le HTML et
le JS :)

Il est vrai que l'on peut toujours se ramener à une racine
d'arborescence qui soit un script PHP, mais n'oublions pas que la page
d'accueil, elle, est le plus souvent une page HTML: index.html

Ah? rappelons tout de même que 99.9% des serveurs acceptant le php
prennent comme page d'index les .htm, .html et .php

[snip]

Il me semble toujours plus simple d'avoir une page de type "ossature"
qui va appeler différentes parties, mais tout dépend du site.
S'il contient des pages complètement différentes, aucun intérêt, c'est
clair. Mais si le site contient 2 types de pages (habituellement un
accueil et le reste), autant avoir "le reste" sous forme modularisée.

D'un autre coté, c'est un avis qui vaut ce qu'il vaut et n'engage que
moi, mais j'ai eu l'habitude de faire des projets dans lesquels les
pages avaient tendance à s'ajouter au fur et à mesure... c'est tout de
même plus simple de copier l'ossature et d'ajouter un module dans les
possibilités d'includes :)

@+
--
Découvrez Original War: http://www.original-war.org
Humour: http://www.chatfou.com
Tchattez en liberté: http://www.crazy-irc.net

Vous avez filtré cet utilisateur ! Consultez son message

Jean-Francois Ortolo wrote:

Bonjour Monsieur

Tutoyons nous, ce sera plus convivial :)

Oui, bien que pour les javascripts, il suffit de la vraie balise html:
<script language="javascript" src="./repertoire/fichier.js"></script>
Pour passer des variables PHP à des scripts JavaScript, il me semble

qu'il faut nécéssairement passer par un script en PHP contenant des
instruction echo ( ou print ), contenant le code HTML appelant le script
JS adéquat.

En effet, mais il vaut mieux le faire à bon escient.
Pour ma part, et même si je suis l'avis auquel je me réfère, j'ai
tendance à éviter l'inclusion de variables PHP dans le JS.
Sachant que ces variables sont toujours pour de l'initialisation, autant
créer une fonction JS à laquelle on passe les variables JS au chargement
de la page (<body onload="initialyze(.....);">)

Je disais: "Dans des pages HTML".

Oui, mais dans le post initial, on parlait de séparer le PHP, le HTML et
le JS :)

Il est vrai que l'on peut toujours se ramener à une racine
d'arborescence qui soit un script PHP, mais n'oublions pas que la page
d'accueil, elle, est le plus souvent une page HTML: index.html

Ah? rappelons tout de même que 99.9% des serveurs acceptant le php
prennent comme page d'index les .htm, .html et .php

[snip]

Il me semble toujours plus simple d'avoir une page de type "ossature"
qui va appeler différentes parties, mais tout dépend du site.
S'il contient des pages complètement différentes, aucun intérêt, c'est
clair. Mais si le site contient 2 types de pages (habituellement un
accueil et le reste), autant avoir "le reste" sous forme modularisée.

D'un autre coté, c'est un avis qui vaut ce qu'il vaut et n'engage que
moi, mais j'ai eu l'habitude de faire des projets dans lesquels les
pages avaient tendance à s'ajouter au fur et à mesure... c'est tout de
même plus simple de copier l'ossature et d'ajouter un module dans les
possibilités d'includes :)

@+
--
Découvrez Original War: http://www.original-war.org
Humour: http://www.chatfou.com
Tchattez en liberté: http://www.crazy-irc.net

John GALLET

21/07/2005 à 11:31

... qui est AMHA un exemple typique d'enculage de mouche^Mcomplication
inutile à la Java.

"Dans mes bras" (tm).

JG

Pierre Maurette

21/07/2005 à 22:02

[...]

pour ma part je
suet muet d'effroi
Vous avez le mutisme un tantinet verbeux, ne trouvez-vous pas ?

--
Pour répondre directement: enlever une lettre sur deux
wwaannaaddoooo -> wanadoo

Pierre Maurette

bruno modulix

21/07/2005 à 22:02

ftc wrote:

Eric Guirbal wrote:

Je vous conseille de lire l'article suivant:
Serge Tahe, Méthodologie de développement MVC d'une application
WEB/PHP,
ftp://ftp-developpez.com/tahe/fichiers-archive/progwebphpmvc-250305.pdf

... qui est AMHA un exemple typique d'enculage de mouche^Mcomplication

inutile à la Java.

(snip)

C'est quand même très pratique d'utiliser un framework MVC quand
l'application commence à devenir un minimum complexe

Même avant !-)

Je ne critique en rien le principe du MVC (cf mon autre post en réponse
à l'OP), je critique cet exemple précis d'implémentation du MVC en PHP.

et ceci même en
PHP. D'autant qu'on force la séparation du code et de la présentation,
s/code/logique métier/

Et c'est même une séparation plus importante encore, puisque le
controleur (appelons ça la logique applicative) vient se placer entre
logique métier et la présentation...

ce qui est à mon avis une très bonne chose.

Ai-je dit le contraire ?-)

Une fois le fonctionnement du framework assimilé, le complication est
effacée.

Non. La complication reste, à chaque exécution. Mon expérience est que
vu le modèle d'exécution de PHP, il est réellement préférable de faire
au plus simple - et il y a des façons beaucoup plus simples de mettre en
place un MVC en PHP que ce qui est proposé dans cet article.

MVC existait avant Java
Oui, ça date des premiers Smalltalk (mais dans un tout autre contexte,

celui des interfaces graphiques en client lourd).

--
bruno desthuilliers
ruby -e "print ''.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"

Francois Girault

21/07/2005 à 23:50

Bonsoir

Je ne critique en rien le principe du MVC (cf mon autre post en réponse
à l'OP), je critique cet exemple précis d'implémentation du MVC en PHP.

Pourriez-vous développer un peu vos critiques et proposer une façon de
faire plus efficace ? ça m'interesse énormément puisque je suis
confronté à l'utilisation d'un MVC dans un progiciel ...

Une fois le fonctionnement du framework assimilé, le complication est
effacée.

Non. La complication reste, à chaque exécution. Mon expérience est que
vu le modèle d'exécution de PHP, il est réellement préférable de faire
au plus simple - et il y a des façons beaucoup plus simples de mettre en
place un MVC en PHP que ce qui est proposé dans cet article.

lesquelles ? ont-elles la même souplesse ? je rêve pronfondément de la
simplicité dont vous parlez !

dans le dernier php-architect, il y avait aussi un article sur la
réalisation d'un MVC, et la solution présentée est très proche de celle
de l'article de phpsol...

merci d'avance pour vos réponses

Bruno Desthuilliers

22/07/2005 à 07:57

Bonsoir

Je ne critique en rien le principe du MVC (cf mon autre post en réponse
à l'OP), je critique cet exemple précis d'implémentation du MVC en PHP.

Pourriez-vous développer un peu vos critiques

Oui: c'est une usine à gaz. Très propre (ce qui est - hélas -trop
rarement le cas en PHP), mais une usine à gaz quand même.

Ce genre de construction est typique de Java (c'est d'ailleurs explicité
en toutes lettres dans le document), a tout son sens en Java (je ne
pense pas que Struts soit un mauvais framework Java), mais n'est pas
idiomatique de PHP, et ne s'accomode pas forcément bien du modèle
d'exécution de PHP (où il faut reconstruire le monde à chaque requête,
avec un interpréteur dont les perfs restent assez moyennes).

et proposer une façon de
faire plus efficace ?

cf mon post en réponse à l'OP. L'exemple est absolument (et
volontairement) d'une simplicité crétinesque, mais ce même principe
fonctionne fort bien pour la moyenne de ce qu'on peut vouloir faire en PHP.

Une fois le fonctionnement du framework assimilé, le complication est
effacée.

Non. La complication reste, à chaque exécution. Mon expérience est que
vu le modèle d'exécution de PHP, il est réellement préférable de faire
au plus simple - et il y a des façons beaucoup plus simples de mettre en
place un MVC en PHP que ce qui est proposé dans cet article.

lesquelles ?

cf mon post en réponse à l'OP. Plus simple, honnêtement, je ne vois pas !-)

ont-elles la même souplesse ?

"la même", je ne sais pas... Une autre, peut-être ?-)

La simplicité est aussi un moyen d'assurer une certaine souplesse.
Maintenant, si on a (réellement...) besoin d'une architecture plus
complexe, il est temps de se tourner vers d'autres environnements (ie :
un langage objet[1] et un serveur d'application - ce qui d'ailleurs
n'implique pas forcément Java, cf Zope, Twisted, ou Rails).

je rêve pronfondément de la
simplicité dont vous parlez !

Essayez Rails, c'est tellement simple que c'est à pleurer. Mais c'est
une simplicité qu'il serait illusoire d'espérer atteindre en PHP (trop
limité) ou en Java (trop rigide).

dans le dernier php-architect, il y avait aussi un article sur la
réalisation d'un MVC, et la solution présentée est très proche de celle
de l'article de phpsol...

Toutes les copies d'un même framework ont tendance à se ressembler. Si
vous faites une recherche PHP + MVC, vous allez trouver pas mal d'autres
clones...

merci d'avance pour vos réponses

De rien - d'autant que je subodore que mes réponses ne vous auront pas
convaincu...

Ah oui, au fait, un dernier point: contrairement à ce que ce post
pourrait laisser croire, je n'ai rien contre la POO (bien au contraire),
ni contre les belles architectures. Par contre, mon expérience est
qu'utiliser un langage à contre-emploi est rarement productif. Vouloir
faire du Java en PHP (ce qui semble être la tendance en ce moment...) me
semble aussi absurde que de vouloir enfoncer une vis avec un marteau.
Bref, utilisons le marteau pour planter des clous, le tournevis pour
visser les vis, et PHP pour ce qu'il sait faire...

Bonsoir

Je ne critique en rien le principe du MVC (cf mon autre post en réponse
à l'OP), je critique cet exemple précis d'implémentation du MVC en PHP.

Pourriez-vous développer un peu vos critiques

Oui: c'est une usine à gaz. Très propre (ce qui est - hélas -trop
rarement le cas en PHP), mais une usine à gaz quand même.

Ce genre de construction est typique de Java (c'est d'ailleurs explicité
en toutes lettres dans le document), a tout son sens en Java (je ne
pense pas que Struts soit un mauvais framework Java), mais n'est pas
idiomatique de PHP, et ne s'accomode pas forcément bien du modèle
d'exécution de PHP (où il faut reconstruire le monde à chaque requête,
avec un interpréteur dont les perfs restent assez moyennes).

et proposer une façon de
faire plus efficace ?

cf mon post en réponse à l'OP. L'exemple est absolument (et
volontairement) d'une simplicité crétinesque, mais ce même principe
fonctionne fort bien pour la moyenne de ce qu'on peut vouloir faire en PHP.

Une fois le fonctionnement du framework assimilé, le complication est
effacée.

Non. La complication reste, à chaque exécution. Mon expérience est que
vu le modèle d'exécution de PHP, il est réellement préférable de faire
au plus simple - et il y a des façons beaucoup plus simples de mettre en
place un MVC en PHP que ce qui est proposé dans cet article.

lesquelles ?

cf mon post en réponse à l'OP. Plus simple, honnêtement, je ne vois pas !-)

ont-elles la même souplesse ?

"la même", je ne sais pas... Une autre, peut-être ?-)

La simplicité est aussi un moyen d'assurer une certaine souplesse.
Maintenant, si on a (réellement...) besoin d'une architecture plus
complexe, il est temps de se tourner vers d'autres environnements (ie :
un langage objet[1] et un serveur d'application - ce qui d'ailleurs
n'implique pas forcément Java, cf Zope, Twisted, ou Rails).

je rêve pronfondément de la
simplicité dont vous parlez !

Essayez Rails, c'est tellement simple que c'est à pleurer. Mais c'est
une simplicité qu'il serait illusoire d'espérer atteindre en PHP (trop
limité) ou en Java (trop rigide).

dans le dernier php-architect, il y avait aussi un article sur la
réalisation d'un MVC, et la solution présentée est très proche de celle
de l'article de phpsol...

Toutes les copies d'un même framework ont tendance à se ressembler. Si
vous faites une recherche PHP + MVC, vous allez trouver pas mal d'autres
clones...

merci d'avance pour vos réponses

De rien - d'autant que je subodore que mes réponses ne vous auront pas
convaincu...

Ah oui, au fait, un dernier point: contrairement à ce que ce post
pourrait laisser croire, je n'ai rien contre la POO (bien au contraire),
ni contre les belles architectures. Par contre, mon expérience est
qu'utiliser un langage à contre-emploi est rarement productif. Vouloir
faire du Java en PHP (ce qui semble être la tendance en ce moment...) me
semble aussi absurde que de vouloir enfoncer une vis avec un marteau.
Bref, utilisons le marteau pour planter des clous, le tournevis pour
visser les vis, et PHP pour ce qu'il sait faire...

Vous avez filtré cet utilisateur ! Consultez son message

Bonsoir

Je ne critique en rien le principe du MVC (cf mon autre post en réponse
à l'OP), je critique cet exemple précis d'implémentation du MVC en PHP.

Pourriez-vous développer un peu vos critiques

Oui: c'est une usine à gaz. Très propre (ce qui est - hélas -trop
rarement le cas en PHP), mais une usine à gaz quand même.

Ce genre de construction est typique de Java (c'est d'ailleurs explicité
en toutes lettres dans le document), a tout son sens en Java (je ne
pense pas que Struts soit un mauvais framework Java), mais n'est pas
idiomatique de PHP, et ne s'accomode pas forcément bien du modèle
d'exécution de PHP (où il faut reconstruire le monde à chaque requête,
avec un interpréteur dont les perfs restent assez moyennes).

et proposer une façon de
faire plus efficace ?

cf mon post en réponse à l'OP. L'exemple est absolument (et
volontairement) d'une simplicité crétinesque, mais ce même principe
fonctionne fort bien pour la moyenne de ce qu'on peut vouloir faire en PHP.

Une fois le fonctionnement du framework assimilé, le complication est
effacée.

Non. La complication reste, à chaque exécution. Mon expérience est que
vu le modèle d'exécution de PHP, il est réellement préférable de faire
au plus simple - et il y a des façons beaucoup plus simples de mettre en
place un MVC en PHP que ce qui est proposé dans cet article.

lesquelles ?

cf mon post en réponse à l'OP. Plus simple, honnêtement, je ne vois pas !-)

ont-elles la même souplesse ?

"la même", je ne sais pas... Une autre, peut-être ?-)

La simplicité est aussi un moyen d'assurer une certaine souplesse.
Maintenant, si on a (réellement...) besoin d'une architecture plus
complexe, il est temps de se tourner vers d'autres environnements (ie :
un langage objet[1] et un serveur d'application - ce qui d'ailleurs
n'implique pas forcément Java, cf Zope, Twisted, ou Rails).

je rêve pronfondément de la
simplicité dont vous parlez !

Essayez Rails, c'est tellement simple que c'est à pleurer. Mais c'est
une simplicité qu'il serait illusoire d'espérer atteindre en PHP (trop
limité) ou en Java (trop rigide).

dans le dernier php-architect, il y avait aussi un article sur la
réalisation d'un MVC, et la solution présentée est très proche de celle
de l'article de phpsol...

Toutes les copies d'un même framework ont tendance à se ressembler. Si
vous faites une recherche PHP + MVC, vous allez trouver pas mal d'autres
clones...

merci d'avance pour vos réponses

De rien - d'autant que je subodore que mes réponses ne vous auront pas
convaincu...

Ah oui, au fait, un dernier point: contrairement à ce que ce post
pourrait laisser croire, je n'ai rien contre la POO (bien au contraire),
ni contre les belles architectures. Par contre, mon expérience est
qu'utiliser un langage à contre-emploi est rarement productif. Vouloir
faire du Java en PHP (ce qui semble être la tendance en ce moment...) me
semble aussi absurde que de vouloir enfoncer une vis avec un marteau.
Bref, utilisons le marteau pour planter des clous, le tournevis pour
visser les vis, et PHP pour ce qu'il sait faire...

CrazyCat

22/07/2005 à 09:49

Pierre Maurette wrote:

pour ma part je
suet muet d'effroi
Vous avez le mutisme un tantinet verbeux, ne trouvez-vous pas ?

Oralement (avec la bouche) muet, pas paralysé :)

--
Découvrez Original War: http://www.original-war.org
Humour: http://www.chatfou.com
Tchattez en liberté: http://www.crazy-irc.net

dmetzler

25/07/2005 à 12:13

Je réagis un peu tard, mais je n'ai pas eu tout de suite le temps de
lire le papier en question !
L'implémentation du MVC en PHP me semble ici pas trop mal faite, mais
ça s'arrête là. A part le mapping des actions dans un tableau, je
vois rien qui ressemble vraiment à des frameworks comme struts.

Ca essaye d'implémenter des concepts objets, mais il n'y a quasiment
aucun objet a part dans la couche DAO. Du coup le code n'est même pas
modulaire. Pour moi l'auteur de l'article s'est embêté à
implémenter des détails alors qu'il est passé totalement à coté du
reste.

Ce qu'il est important de comprendre en PHP, c'est que le code est
réexécuté chaque fois. A chaque fois qu'on appelle une page, il faut
réinstancier tous les objets et il faut donc optimiser les appels
nécessaire. Inutile de se connecter à une base si l'on en n'a pas
besoin par exemple.

Un framework de type MVC n'est pas très difficile à faire et le
meilleur est bien sûr celui qu'on maitrise. Pour ma part, j'ai le mien
que je sais utiliser et qui m'aide plutot bien : Une page = 1
contrôleur + des vues (Templates Smarty). Le contrôleur accède aux
données par les couches métiers. Un ensemble de librairies permet
surtout de ne pas avoir à s'occuper de la logistique (sessions, DB,
authentification etc...) à chaque fois qu'on développe une nouvelle
appli.

L'essentiel est bien sûr d'être pragmatique et faire en sorte que
l'appli fonctionne correctement et efficacement.

Francois Girault

26/07/2005 à 01:13

cf mon post en réponse à l'OP. L'exemple est absolument (et
volontairement) d'une simplicité crétinesque, mais ce même principe
fonctionne fort bien pour la moyenne de ce qu'on peut vouloir faire en PHP.

"la moyenne" ... difficile de trouver plus subjectif :) après il y a
certes la moyenne des faits ... la majorité des applications php n'ont
(peut être pas) la complexité des progicielles contenant des centaines
de classes et leurs centaines d'actions ...

cf mon post en réponse à l'OP. Plus simple, honnêtement, je ne vois pas !-)

il est sur que c'est simple, mais n'est-on pas proche du simpliste dans
ce cas ?

ont-elles la même souplesse ?

"la même", je ne sais pas... Une autre, peut-être ?-)

La simplicité est aussi un moyen d'assurer une certaine souplesse.
Maintenant, si on a (réellement...) besoin d'une architecture plus
complexe, il est temps de se tourner vers d'autres environnements (ie :
un langage objet[1] et un serveur d'application - ce qui d'ailleurs
n'implique pas forcément Java, cf Zope, Twisted, ou Rails).

ah je n'ai pas pu lire le [1], dommage. bizarre comme php5 a
complètement repris le modèle objet de java ;) et qu'un serveur
d'application pour php (SRM) soit moribond.

Essayez Rails, c'est tellement simple que c'est à pleurer. Mais c'est
une simplicité qu'il serait illusoire d'espérer atteindre en PHP (trop
limité) ou en Java (trop rigide).

ah oui, la vidéo de démo de construction d'un blog en 15 min est
effectivement à pleurer tant l'approche est d'une belle simplicité fondé
sur un minimalisme radical. mais ... c'est du ruby non ?

Toutes les copies d'un même framework ont tendance à se ressembler. Si
vous faites une recherche PHP + MVC, vous allez trouver pas mal d'autres
clones...

hé oui, difficile d'échapper à l'inspiration de java dans le monde du
développement ... en même temps c'est grâce à java si de tels design
patterns sont si populaires, on lui doit bien ça !

De rien - d'autant que je subodore que mes réponses ne vous auront pas
convaincu...

effectivement, pas tout à fait ...

Ah oui, au fait, un dernier point: contrairement à ce que ce post
pourrait laisser croire, je n'ai rien contre la POO (bien au contraire),
ni contre les belles architectures. Par contre, mon expérience est
qu'utiliser un langage à contre-emploi est rarement productif. Vouloir
faire du Java en PHP (ce qui semble être la tendance en ce moment...) me
semble aussi absurde que de vouloir enfoncer une vis avec un marteau.
Bref, utilisons le marteau pour planter des clous, le tournevis pour
visser les vis, et PHP pour ce qu'il sait faire...

ne pensez-vous pas que vous avez raté la marche "design patterns" ?
c'est un savoir-faire réutilisable d'un langage à l'autre. la popularité
de java en POO l'a mis de facto comme une implémentation de référence
(cf tous les patterns dispo chez sun, ou sur theserverside) ... et tout
le monde a suivit car les patterns sont fondamentaux dans l'approche
objet. je viens même d'acheter le premier livre sur les patterns en
php5, et il contient de très bonne pratiques.

je suis d'accord qu'il ne faut pas utiliser ce savoir-faire contre la
nature de l'implémentation (reparsing des scripts à chaque hit, etc
...). le faire est d'ailleurs un anti-pattern : golden hammer. il faut
*toujours* garder à l'esprit l'aspect stateless de php, et donc faire
des concessions par rapport au pratiques habituelles de POO. du coup,
vive la créativité dans ce contexte ! sans oublier les patterns qui la
motive ;)

cf mon post en réponse à l'OP. L'exemple est absolument (et
volontairement) d'une simplicité crétinesque, mais ce même principe
fonctionne fort bien pour la moyenne de ce qu'on peut vouloir faire en PHP.

"la moyenne" ... difficile de trouver plus subjectif :) après il y a
certes la moyenne des faits ... la majorité des applications php n'ont
(peut être pas) la complexité des progicielles contenant des centaines
de classes et leurs centaines d'actions ...

cf mon post en réponse à l'OP. Plus simple, honnêtement, je ne vois pas !-)

il est sur que c'est simple, mais n'est-on pas proche du simpliste dans
ce cas ?

ont-elles la même souplesse ?

"la même", je ne sais pas... Une autre, peut-être ?-)

La simplicité est aussi un moyen d'assurer une certaine souplesse.
Maintenant, si on a (réellement...) besoin d'une architecture plus
complexe, il est temps de se tourner vers d'autres environnements (ie :
un langage objet[1] et un serveur d'application - ce qui d'ailleurs
n'implique pas forcément Java, cf Zope, Twisted, ou Rails).

ah je n'ai pas pu lire le [1], dommage. bizarre comme php5 a
complètement repris le modèle objet de java ;) et qu'un serveur
d'application pour php (SRM) soit moribond.

Essayez Rails, c'est tellement simple que c'est à pleurer. Mais c'est
une simplicité qu'il serait illusoire d'espérer atteindre en PHP (trop
limité) ou en Java (trop rigide).

ah oui, la vidéo de démo de construction d'un blog en 15 min est
effectivement à pleurer tant l'approche est d'une belle simplicité fondé
sur un minimalisme radical. mais ... c'est du ruby non ?

Toutes les copies d'un même framework ont tendance à se ressembler. Si
vous faites une recherche PHP + MVC, vous allez trouver pas mal d'autres
clones...

hé oui, difficile d'échapper à l'inspiration de java dans le monde du
développement ... en même temps c'est grâce à java si de tels design
patterns sont si populaires, on lui doit bien ça !

De rien - d'autant que je subodore que mes réponses ne vous auront pas
convaincu...

effectivement, pas tout à fait ...

Ah oui, au fait, un dernier point: contrairement à ce que ce post
pourrait laisser croire, je n'ai rien contre la POO (bien au contraire),
ni contre les belles architectures. Par contre, mon expérience est
qu'utiliser un langage à contre-emploi est rarement productif. Vouloir
faire du Java en PHP (ce qui semble être la tendance en ce moment...) me
semble aussi absurde que de vouloir enfoncer une vis avec un marteau.
Bref, utilisons le marteau pour planter des clous, le tournevis pour
visser les vis, et PHP pour ce qu'il sait faire...

ne pensez-vous pas que vous avez raté la marche "design patterns" ?
c'est un savoir-faire réutilisable d'un langage à l'autre. la popularité
de java en POO l'a mis de facto comme une implémentation de référence
(cf tous les patterns dispo chez sun, ou sur theserverside) ... et tout
le monde a suivit car les patterns sont fondamentaux dans l'approche
objet. je viens même d'acheter le premier livre sur les patterns en
php5, et il contient de très bonne pratiques.

je suis d'accord qu'il ne faut pas utiliser ce savoir-faire contre la
nature de l'implémentation (reparsing des scripts à chaque hit, etc
...). le faire est d'ailleurs un anti-pattern : golden hammer. il faut
*toujours* garder à l'esprit l'aspect stateless de php, et donc faire
des concessions par rapport au pratiques habituelles de POO. du coup,
vive la créativité dans ce contexte ! sans oublier les patterns qui la
motive ;)

Vous avez filtré cet utilisateur ! Consultez son message

cf mon post en réponse à l'OP. L'exemple est absolument (et
volontairement) d'une simplicité crétinesque, mais ce même principe
fonctionne fort bien pour la moyenne de ce qu'on peut vouloir faire en PHP.

"la moyenne" ... difficile de trouver plus subjectif :) après il y a
certes la moyenne des faits ... la majorité des applications php n'ont
(peut être pas) la complexité des progicielles contenant des centaines
de classes et leurs centaines d'actions ...

cf mon post en réponse à l'OP. Plus simple, honnêtement, je ne vois pas !-)

il est sur que c'est simple, mais n'est-on pas proche du simpliste dans
ce cas ?

ont-elles la même souplesse ?

"la même", je ne sais pas... Une autre, peut-être ?-)

La simplicité est aussi un moyen d'assurer une certaine souplesse.
Maintenant, si on a (réellement...) besoin d'une architecture plus
complexe, il est temps de se tourner vers d'autres environnements (ie :
un langage objet[1] et un serveur d'application - ce qui d'ailleurs
n'implique pas forcément Java, cf Zope, Twisted, ou Rails).

ah je n'ai pas pu lire le [1], dommage. bizarre comme php5 a
complètement repris le modèle objet de java ;) et qu'un serveur
d'application pour php (SRM) soit moribond.

Essayez Rails, c'est tellement simple que c'est à pleurer. Mais c'est
une simplicité qu'il serait illusoire d'espérer atteindre en PHP (trop
limité) ou en Java (trop rigide).

ah oui, la vidéo de démo de construction d'un blog en 15 min est
effectivement à pleurer tant l'approche est d'une belle simplicité fondé
sur un minimalisme radical. mais ... c'est du ruby non ?

Toutes les copies d'un même framework ont tendance à se ressembler. Si
vous faites une recherche PHP + MVC, vous allez trouver pas mal d'autres
clones...

hé oui, difficile d'échapper à l'inspiration de java dans le monde du
développement ... en même temps c'est grâce à java si de tels design
patterns sont si populaires, on lui doit bien ça !

De rien - d'autant que je subodore que mes réponses ne vous auront pas
convaincu...

effectivement, pas tout à fait ...

Ah oui, au fait, un dernier point: contrairement à ce que ce post
pourrait laisser croire, je n'ai rien contre la POO (bien au contraire),
ni contre les belles architectures. Par contre, mon expérience est
qu'utiliser un langage à contre-emploi est rarement productif. Vouloir
faire du Java en PHP (ce qui semble être la tendance en ce moment...) me
semble aussi absurde que de vouloir enfoncer une vis avec un marteau.
Bref, utilisons le marteau pour planter des clous, le tournevis pour
visser les vis, et PHP pour ce qu'il sait faire...

ne pensez-vous pas que vous avez raté la marche "design patterns" ?
c'est un savoir-faire réutilisable d'un langage à l'autre. la popularité
de java en POO l'a mis de facto comme une implémentation de référence
(cf tous les patterns dispo chez sun, ou sur theserverside) ... et tout
le monde a suivit car les patterns sont fondamentaux dans l'approche
objet. je viens même d'acheter le premier livre sur les patterns en
php5, et il contient de très bonne pratiques.

je suis d'accord qu'il ne faut pas utiliser ce savoir-faire contre la
nature de l'implémentation (reparsing des scripts à chaque hit, etc
...). le faire est d'ailleurs un anti-pattern : golden hammer. il faut
*toujours* garder à l'esprit l'aspect stateless de php, et donc faire
des concessions par rapport au pratiques habituelles de POO. du coup,
vive la créativité dans ce contexte ! sans oublier les patterns qui la
motive ;)

Gill

27/07/2005 à 08:22

Je voudrais savoir comment vous procéder pour bien séparer la forme (en
gros

html+css) du fond (le code PHP) ?

http://vtemplate.sourceforge.net/

Ca donne du code PHP comme :

include_once "VTemplate.class.php";
$vtp = New VTemplate;

// traitement PHP (_POST, _GET, mySQL....)
(...)
//on charge les différentes pages html
$vtp_struct = $vtp->Open("structure.html");
$vtp_page = $vtp->Open("page1.html");
$vtp_somm = $vtp->Open("sommaire.html");

// on valorise les zones VTemplates prévues dans le HTML
$vtp->addSession($vtp_somm, "ZONE");
//on met un texte en italique, par exemple, ou on ajoute un tableau,
etc... selon les conditions calculées au-dessus.
$vtp->setVar($vtp_page, "ZONE.VAR_STYLEBLOC", "italic");
$vtp->closeSession($vtp_somm, "ZONE");

$vtp->addSession($vtp_page, "ZONE");
//on insère le SOMMAIRE latéral dans la PAGE
$vtp->Parse($vtp_page,"ZONE.VAR_SOMMAIRE", $vtp_somm,"ZONE");
$vtp->closeSession($vtp_page, "ZONE");

$vtp->addSession($vtp_struct, "ZONE");
//on insère la PAGE dans LA STRUCTURE de page (= entête + page + sommaire
latéral))
$vtp->Parse($vtp_struct,"ZONE.VAR_PAGE", $vtp_page,"ZONE");
$vtp->closeSession($vtp_struct, "ZONE");

//et on affiche le montage de ces 3 pages html ! (création du code HTML
final)
$vtp->Display($vtp_struct);

------------------------------
page1.html :

<html><head></head><body>

(...)


(...)

{#VAR_SOMMAIRE}
(...)




</body></html>

------------------------------
sommaire.html :
(...)

<span style="{#VAR_STYLEBLOC}">mon texte qui sera en italique si
besoin</span>

(...)

Bref : Séparation parfaite du code PHP et du HTML/CSS !

Je voudrais savoir comment vous procéder pour bien séparer la forme (en
gros

html+css) du fond (le code PHP) ?

http://vtemplate.sourceforge.net/

Ca donne du code PHP comme :

include_once "VTemplate.class.php";
$vtp = New VTemplate;

// traitement PHP (_POST, _GET, mySQL....)
(...)
//on charge les différentes pages html
$vtp_struct = $vtp->Open("structure.html");
$vtp_page = $vtp->Open("page1.html");
$vtp_somm = $vtp->Open("sommaire.html");

// on valorise les zones VTemplates prévues dans le HTML
$vtp->addSession($vtp_somm, "ZONE");
//on met un texte en italique, par exemple, ou on ajoute un tableau,
etc... selon les conditions calculées au-dessus.
$vtp->setVar($vtp_page, "ZONE.VAR_STYLEBLOC", "italic");
$vtp->closeSession($vtp_somm, "ZONE");

$vtp->addSession($vtp_page, "ZONE");
//on insère le SOMMAIRE latéral dans la PAGE
$vtp->Parse($vtp_page,"ZONE.VAR_SOMMAIRE", $vtp_somm,"ZONE");
$vtp->closeSession($vtp_page, "ZONE");

$vtp->addSession($vtp_struct, "ZONE");
//on insère la PAGE dans LA STRUCTURE de page (= entête + page + sommaire
latéral))
$vtp->Parse($vtp_struct,"ZONE.VAR_PAGE", $vtp_page,"ZONE");
$vtp->closeSession($vtp_struct, "ZONE");

//et on affiche le montage de ces 3 pages html ! (création du code HTML
final)
$vtp->Display($vtp_struct);

------------------------------
page1.html :

<html><head></head><body>

(...)


(...)

{#VAR_SOMMAIRE}
(...)




</body></html>

------------------------------
sommaire.html :
(...)

<span style="{#VAR_STYLEBLOC}">mon texte qui sera en italique si
besoin</span>

(...)

Bref : Séparation parfaite du code PHP et du HTML/CSS !

Vous avez filtré cet utilisateur ! Consultez son message

Je voudrais savoir comment vous procéder pour bien séparer la forme (en
gros

html+css) du fond (le code PHP) ?

http://vtemplate.sourceforge.net/

Ca donne du code PHP comme :

include_once "VTemplate.class.php";
$vtp = New VTemplate;

// traitement PHP (_POST, _GET, mySQL....)
(...)
//on charge les différentes pages html
$vtp_struct = $vtp->Open("structure.html");
$vtp_page = $vtp->Open("page1.html");
$vtp_somm = $vtp->Open("sommaire.html");

// on valorise les zones VTemplates prévues dans le HTML
$vtp->addSession($vtp_somm, "ZONE");
//on met un texte en italique, par exemple, ou on ajoute un tableau,
etc... selon les conditions calculées au-dessus.
$vtp->setVar($vtp_page, "ZONE.VAR_STYLEBLOC", "italic");
$vtp->closeSession($vtp_somm, "ZONE");

$vtp->addSession($vtp_page, "ZONE");
//on insère le SOMMAIRE latéral dans la PAGE
$vtp->Parse($vtp_page,"ZONE.VAR_SOMMAIRE", $vtp_somm,"ZONE");
$vtp->closeSession($vtp_page, "ZONE");

$vtp->addSession($vtp_struct, "ZONE");
//on insère la PAGE dans LA STRUCTURE de page (= entête + page + sommaire
latéral))
$vtp->Parse($vtp_struct,"ZONE.VAR_PAGE", $vtp_page,"ZONE");
$vtp->closeSession($vtp_struct, "ZONE");

//et on affiche le montage de ces 3 pages html ! (création du code HTML
final)
$vtp->Display($vtp_struct);

------------------------------
page1.html :

<html><head></head><body>

(...)


(...)

{#VAR_SOMMAIRE}
(...)




</body></html>

------------------------------
sommaire.html :
(...)

<span style="{#VAR_STYLEBLOC}">mon texte qui sera en italique si
besoin</span>

(...)

Bref : Séparation parfaite du code PHP et du HTML/CSS !

Separer le code PHP du reste

10 réponses

Veuillez sélectionner un problème