Separer le code PHP du reste

Gill wrote:

UniversZen wrote:

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 :

(snip exemple)

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

Oui. Mais la vraie question est-elle de séparer le PHP du HTML [1] ou de
séparer la logique métier de la présentation ?

J'ai vu des applications PHP basés sur des systèmes de template où,
effectivement, il n'y a pas une ligne de PHP dans les templates. Le
mélange entre logique métier et logique de présentation a simplement été
déplacé de la présentation vers l'application. Honnêtement, je ne sais
pas dans quelle mesure c'est un progrès :(

Ca ne signifie pas que les systèmes de template soient forcément
inutiles ou nuisible [1 aussi]. Juste que le problème à resoudre n'est
(AMHA) pas celui résolu par les templates, même si un système de
template peut faire partie de la solution - et PHP *est* un système de
template, n'est-ce pas ?-)


[1] Il est clair que si un non-programmeur, voire un utilisateur final,
doit pouvoir intervenir sur la présentation, il est préférable que la
présentation ne puisse pas contenir de PHP !-)


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

Francois Girault wrote:

<meta>
xpost et fu fr.comp.objet, il me semble qu'on commence franchement à
sortir de la chartes de f.c.l.php
</meta>

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 ...

Non, justement. Mais on peut se demander si cette complexité est
inhérente à l'application ou au langage... Le langage peut avoir une
influence non négligeable sur la complexité de l'implémentation pour un
même niveau de complexité du point de vue fonctionnel.

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 ?

Mon expérience (en général, et tout particulièrement en PHP) est que
plus c'est simple, mieux ça marche. Maintenant, il y a effectivement une
différence entre "la chose la plus simple qui puisse marcher" et le
simplisme.

L'exemple que je donnais était bien sûr (volontairement) simpliste -
crétinesque serait plus approprié - puisqu'il s'agissait juste
d'illustrer un principe (une "architecture" si on veut être
buzzword-compliant). Mais le traditionnel "hello world" en java/struts
est lui aussi simpliste par rapport à une véritable application struts.
Par contre, il est *beaucoup* plus complexe que son équivalent en PHP !-)

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.

Désolé. Le voici:

[1]
<std-disclaimer>
Oui, je sais, php supporte maintenant quelques idiomes OO. Ca n'en fait
pas un langage OO pour autant (AMHA), de même qu'il ne suffit pas
d'utiliser des classes et des objets pour faire de l'OO.
</std-disclaimer>

bizarre comme php5 a
complètement repris le modèle objet de java ;)

:(

Une erreur stratégique majeure AMHA. PHP ne devrait pas essayer de
devenir un meilleur Java, il faudrait mieux qu'il devienne un meilleur PHP.

et qu'un serveur
d'application pour php (SRM) soit moribond.

Tiens, je ne connais pas. Je vais aller voir...

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.

isn't it ?-)

mais ... c'est du ruby non ?

Exactement !-)

C'est bien à ça que je veux en venir : un langage, ce n'est pas
seulement une grammaire et une syntaxe, c'est aussi et surtout une
philosophie et des idiomes. Transposer un idiome d'un langage à un autre
peut s'avérer contre-productif, surtout quand les philosophies
diffèrent. Même Python et Ruby, pourtant très proches, ne sont guère
compatibles de ce point de vue.

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 ...

Ah bon ?

<troll>
Dans mon cas, ce serait plutôt une "contre-inspiration", alors !-)
</troll>

Plus sérieusement, j'aimerais savoir en quoi Java a inspiré Python en
général, et Zope en particulier.

en même temps c'est grâce à java si de tels design
patterns sont si populaires, on lui doit bien ça !

Hmmm... Je ne me souviens pas avoir vu une seule ligne de Java dans le
Gof. Seulement du C++ et du Smalltalk.

Le marketing intensif autour de Java a certainement participé à imposer
une certaine vision (très réductrice AMHA) de l'OO, et il est clair que
vu la rigidité psychotique de ce langage, l'usage intensif des design
patterns (dont la finalité générale est à peu près toujours d'introduire
davantage de dynamisme) est incontournable. Pour le reste,

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

effectivement, pas tout à fait ...

Il y a des choses qu'il faut expérimenter par soi-même...

<anecdote>
Quand j'ai commencer à explorer Python - j'étais à l'époque un
inconditionnel du typage statique -, ma première réaction a été de
vouloir réintroduire un modèle à la Java (getters/setters, interfaces,
contrôle de type etc), avant de réaliser que tout cela était
parfaitement superflu et généralement nuisible en Python, et qu'il était
bien plus efficace de s'imprégner de la philosophie Python que de
vouloir faire du Java en Python.

De la même façon, je n'essaierais pas de faire du Python en Java, ça
n'aurait pas plus de sens. Chaque langage tends vers sa cohérence
interne, et apprendre un langage consiste avant tout à entrer dans cette
cohérence (AMHA).

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" ?

Pas vraiment, non. Vous voulez qu'on en discute ?-) (dans ce cas, il
faudrait placer le fu2 -> f.c.objet)

c'est un savoir-faire réutilisable d'un langage à l'autre.

"réutilisable" quand on fait abstraction des implémentations existantes
dans d'autres langages que le langage cible. Le fait est que
l'implémentation effective peut être *très* différente des exemples du
Gof ou des implémentations 'canoniques' diffusées par Java.

la popularité
de java en POO l'a mis de facto comme une implémentation de référence

Le propre d'un pattern est justement d'être indépendant de
l'implémentation, non ?

Si vous regardez de plus près l'exemple simpliste que je donnais à l'OP,
vous verrez qu'il s'agit bien d'un MVC 'sauce web' (qui est quand même
très différent du MVC d'origine tel que popularisé par Smalltalk), même
si l'implémentation ne ressemble en rien à celle qu'on voit
habituellement en Java.

(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.

Tout à fait. Mais vouloir calquer *l'implémentation* d'un pattern d'un
langage à un autre relève de la même classe d'erreur que de vouloir
"forcer" des idiomes d'un langage dans un autre : cela n'a de sens que
si les deux langages sont suffisament proches (pas tant par la syntaxe
que par la philosophie et les idiomes).

je viens même d'acheter le premier livre sur les patterns en
php5, et il contient de très bonne pratiques.

Dois-je préciser que je ne suis absolument pas convaincu (et c'est un
euphémisme...) par l'évolution actuelle de PHP ? Si c'est pour faire du
Java, j'aime autant (enfin, façon de parler...) prendre l'original.

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.

Ah tiens ? En fait, on est d'accord, alors ?-)

Enfin presque...

Il ne s'agit pas AMHA de "faire des concessions par rapport au pratiques
habituelles de POO", mais d'éviter de vouloir imposer un modèle (en
l'occurrence le modèle Java, mais ce n'est pas le point essentiel) dans
un contexte où cela n'a aucun sens. On peut appliquer des concept[ion]s
objets sans utiliser de classes (ni de prototypes d'ailleurs, cf Self,
Io, Javascript...).

En ce qui me concerne, implémenter le MVC avec:
- des tableaux et des fonctions comme modèle
- un script[1] comme controleur
- des 'templates' PHP comme vues
me semble une approche parfaitement valide dans le contexte qui nous
intéresse ici. Le fait qu'il n'y ait pas ou peu de classes et
d'instances de classes impliqués n'enlève rien à la validité de
l'approche. C'est un détail d'implémentation, pas un point de conception.

du coup,
vive la créativité dans ce contexte ! sans oublier les patterns qui la
motive ;)

Les patterns sont des propositions de solutions, pas des impératifs de
conception. A priori, je ne commence pas une conception en me demandant
quels patterns je vais utiliser. J'essaie surtout d'être attentif durant
la conception (et l'implémentation) à reconnaitre les forces et
conditions qui pourraient suggérer l'emploi de tel ou tel pattern.

NB: le cas du MVC (mais est-ce bien un design pattern à proprement
parler ? là aussi, les avis divergent) est particulier, en ce qu'il me
semble difficile de construire propement une application interactive
sans y recourir d'une façon ou d'une autre - même si certains frameworks
(la plupart des GUI toolkits modernes par exemple) "masquent" plus ou
moins la partie Controleur en gérant déjà le dispatch des actions de
l'utilisateur vers des fonctions de rappel.


Mes deux centimes...
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"

J'ai vu des applications PHP basés sur des systèmes de template où,
effectivement, il n'y a pas une ligne de PHP dans les templates. Le
mélange entre logique métier et logique de présentation a simplement été
déplacé de la présentation vers l'application. Honnêtement, je ne sais
pas dans quelle mesure c'est un progrès :(
PHP *est* un système de template, n'est-ce pas ?-)

Toutafé ! Et on peut tout aussi bien l'utiliser de manière brouillonne que
propre. Séparer le moteur et la présentation dans un même document ou dans
plusieurs... ou utiliser des macros qui obligent à le faire... c'est à dire
les systèmes de Templates.
Certains programmeurs préfèrent avoir accès au code *à coté* ou "au sein" de
la présentation dans laquelle il joue un rôle (mélange PHP/HTML) pour les
retrouver plus facilement, plus instinctivement.
D'autres font appel à un "tableau de commande" bien commenté pour piloter
l'interface "à distance" avec une approche "métier".
Il me semble pourtant que la première approche (qui convient parfaitement
pour des petits projets : un bon de commande, par ex) oublie un point : il
arrive très souvent que l'on doive inspecter les fonctions/classes qui sont
déployées dans l'interface. On doit donc remonter à la source, c'est à dire
à l'endroit de notre bibliothèque de fonctions/classes... Or, l'utilisateur
de Templates/macros, lui, est déjà "sur place" !
Quoique... Il séparera forcément lui aussi la partie bibliothèque de la
partie applicative...
Boarf ! Effectivement, ce n'est pas si probant que ça...

[1] Il est clair que si un non-programmeur, voire un utilisateur final,
doit pouvoir intervenir sur la présentation, il est préférable que la
présentation ne puisse pas contenir de PHP !-)

C'est EXACTEMENT pour ça que j'utilise VTemplate ! :-D !

Merci à tous, je vais me pencher sur le sujet ! ;-)

Et en cas de pb, comme dirait l'autre : "je reviendrai !" lol

A+.


--
UniversZen