j'apprends php 2
Olivier Masson
Je continue mon apprentissage actif avec la lecture de "PHP5 avanc�" qui
est un peu creux, comme de nombreux livres de ce type, mais bon, �a
parle un peu objet, c'est d�j� �a.
Mes interrogations actuelles concernent les divers outils et concepts
populaires.
Tout d'abord, je n'ai pas compris l'utilit� d'un ORM. J'ai regard� la
tr�s concise pr�sentation de Doctrine sur wikipedia, mais c'est un CRUD.
Donc, en gros, � quoi sert un ORM ?
Ensuite, la fameuse question des frameworks. J'utiliserais bien
volontiers un framework solide puisque je consid�re qu'un tel outil,
con�u et entretenu par des dev tr�s comp�tents (en tout cas cent fois
plus que moi) et corrig� par beaucoup de monde pourrait �tre tr�s utile
et productif.
Seulement, il y a deux points qui m'effraient :
- la lourdeur de certains (symphony)
- la vitesse de changement des versions avec pas mal d'incompatibilit�s
ascendantes (� peine peut-on finir un projet sous ZF 1.6 que la 1.8
sort, etc.)
Pour le premier point, � l'inverse, un CakePHP ne contient pas grand
chose (du moins pas suffisamment pour que je puisse y trouver un r�el
int�r�t, je crois). Mais un Symfony semble �norme et on n'est plus dans
l'utilisation de briques (ce que j'aurais voulu) mais directement dans
l'�laboration d'un immeuble... m�me si l'on souhaite construire un muret.
Pour le second point, c'est surement un avantage, mais c'est assez
d�courageant car si je pars dans l'apprentissage de ZF N ou Symfony M,
quel temps devrais-je encore consacrer pour me faire � la N+1 ou M+1 ?
Merci de votre attention :)
Pascal
> Bonjour,
Bonjour,
> Tout d'abord, je n'ai pas compris l'utilit� d'un ORM. J'ai regard� la
> tr�s concise pr�sentation de Doctrine sur wikipedia, mais c'est un CRUD.
> Donc, en gros, � quoi sert un ORM ?
Pour moi, un ORM est une sorte de CRUD version POO.
Il permet � un m�me programme applicatif d'adresser des requ�tes SQL �
une base de donn�es relationnelle, ind�pendamment du SGBDR utilis�.
Ce syst�me devient, �videmment, inutile (ou tr�s all�g�) si on s'adresse
� une base de donn�es orient�e objet.
> Ensuite, la fameuse question des frameworks. J'utiliserais bien
> volontiers un framework solide puisque je consid�re qu'un tel outil,
> con�u et entretenu par des dev tr�s comp�tents (en tout cas cent fois
> plus que moi) et corrig� par beaucoup de monde pourrait �tre tr�s utile
> et productif.
Avec un peu de recul, je dirais qu'il y a un malentendu � propos des
frameworks (ou cadriciels, pour les acad�miciens scrupuleux).
Ceux-ci, quelque soit le langage, semblent plut�t destin�s � construire
des applications lourdes, comme celles d�velopp�es par des �diteurs,
open source ou pas (par exemple un CMS bas� sur Zend Framework).
Dans ce contexte, il est n�cessaire d'avoir une architecture modulaire
tr�s pouss�e et une grande robustesse du code, ce qui justifie l'emploi
de tels outils et la tol�rance en regard de leurs co�ts d'appropriation
et d'exploitation (lourdeur, lenteur, apprentissage, personnalisation).
En dehors de ces cas, et sp�cifiquement pour PHP, je conseillerais deux
solutions :
1. Classiquement, pour des petits projets, peu �volutifs et non
modularis�s, ne pas oublier que PHP est d�j� en lui-m�me un syst�me de
templates. Donc, juste s�parer la partie "applicative" (PHP, objet ou
pas) de la pr�sentation (HTML + quelques "echo", boucles et tests PHP).
2. Pour des projets moyens, mais �volutifs et modularis�s, construire
son propre framework all�g�. Un MVC en POO peut �tre une bonne id�e dans
ce cas, sans rien exag�rer dans son architecture (pas d'usine � gaz).
Cordialement,
Pascal
Abr�viations utilis�es (pour tous) :
- ORM, Object-Relational Mapping
- CRUD, Create/Retrieve/Update/Delete
- POO, Programmation Orient�e Objet
- SGBDR, Syst�me de Gestion de Base de Donn�es Relationnelle
- CMS, Content Management System (ou Software)
- MVC, Model/Controller/View
Bruno Desthuilliers
> Bonjour,
>
> Je continue mon apprentissage actif avec la lecture de "PHP5 avanc�" qui
> est un peu creux, comme de nombreux livres de ce type,
s/de nombreux/la grande majorit�/
> mais bon, �a
> parle un peu objet, c'est d�j� �a.
Je pense qu'il y a plus int�ressant comme litt�rature sur l'OO...
> Mes interrogations actuelles concernent les divers outils et concepts
> populaires.
>
> Tout d'abord, je n'ai pas compris l'utilit� d'un ORM. J'ai regard� la
> tr�s concise pr�sentation de Doctrine sur wikipedia, mais c'est un CRUD.
> Donc, en gros, � quoi sert un ORM ?
Ca d�pend du contexte...
L'id�e de base est d'utiliser des classes m�tier persistantes au lieu de
"rows" bruts tels que retourn�s par la base de donn�e, et donc de
pouvoir d'une part encapsuler toute les r�gles m�tier en un seul endroit
et d'autre part abstraire l'essentiel du SQL (en d�l�guant sa g�n�ration
� l'ORM).
L'int�r�t effectif d�pend du type d'application, du langage et de la
techno (server page ou long running process), de l'ORM lui-m�me... Dans
Django (ORM sp�cifique) ou Pylons (SQLAlchemy), �a fonctionne plut�t
bien. En PHP, ceux que j'ai vu passer personnellement �taient cod�s avec
les pieds et pr�sentaient plus d'inconv�nient que d'avantages - mais
honn�tement je n'en ai pas essay� tant que �a. A vrai dire, je ne pense
pas que la techno PHP (langage proc�dural avec un mod�le objet rikiki,
mod�le d'ex�cution server page avec reconstruction du "monde" entier �
chaque requ�te HTTP, etc) se pr�te vraiment � cette approche (mon humble
avis, hein...).
>
> Ensuite, la fameuse question des frameworks. J'utiliserais bien
> volontiers un framework solide puisque je consid�re qu'un tel outil,
> con�u et entretenu par des dev tr�s comp�tents (en tout cas cent fois
> plus que moi)
Hem... Y a a boire et � manger. Et certains trucs dont, quand tu regarde
le code, tu te dis que tu es probablement trop modeste, et qu'il y a
nettement plus incomp�tent que toi.
> et corrig� par beaucoup de monde pourrait �tre tr�s utile
> et productif.
> Seulement, il y a deux points qui m'effraient :
> - la lourdeur de certains (symphony)
"lourdeur" dans quel sens ? Complexit�, ou mauvaises performances ?
> - la vitesse de changement des versions avec pas mal d'incompatibilit�s
> ascendantes (� peine peut-on finir un projet sous ZF 1.6 que la 1.8
> sort, etc.)
> Pour le premier point, � l'inverse, un CakePHP ne contient pas grand
> chose (du moins pas suffisamment pour que je puisse y trouver un r�el
> int�r�t, je crois).
On a test� CakePHP sur un (petit) projet, on n'est pas pr�s d'y revenir.
> Mais un Symfony semble �norme et on n'est plus dans
> l'utilisation de briques (ce que j'aurais voulu) mais directement dans
> l'�laboration d'un immeuble... m�me si l'on souhaite construire un muret.
C'est effectivement le probl�me avec la plupart des frameworks - et la
contrepartie d'un ensemble (suppos�) coh�rent et bien int�gr�.
D'un autre c�t�, m�me si �a semble parfois overkill pour des projets
simples, un bon framework peut aussi aider � construire rapidement un
muret - avec la possibilit� d'en faire un immeuble par la suite sans
devoir raser le muret d'abord !-)
Je termine actuellement une petite galerie virtuelle toute simple pour
un ami peintre, et l'�crire avec Django m'aura pris moins longtemps que
de le coder en PHP pur et dur ou d'adapter un CMS existant - avec au
final un truc sur mesure.
> Pour le second point, c'est surement un avantage, mais c'est assez
> d�courageant car si je pars dans l'apprentissage de ZF N ou Symfony M,
> quel temps devrais-je encore consacrer pour me faire � la N+1 ou M+1 ?
Ca d�pend de la politique du projet - certains essayent d'�tre assez
conservateurs (et donc de rester aussi compatibles que possible d'une
version � une autre, et de bien documenter les rares incompatibilit�s),
d'autres s'en fiche royalement. Dans le premier cas, c'est comme avec
n'importe quel outil, une fois le "premier apprentissage" effectu�,
suivre les �volutions est assez facile, � condition de "pratiquer"
l'outil de fa�on r�guli�re et de suivre __effectivement__ les
�volutions. Dans le second cas, bin, le mieux est probablement d'�viter
l'outil !-)
Olivier Masson
> Pour moi, un ORM est une sorte de CRUD version POO.
> Il permet � un m�me programme applicatif d'adresser des requ�tes SQL �
> une base de donn�es relationnelle, ind�pendamment du SGBDR utilis�.
> Ce syst�me devient, �videmment, inutile (ou tr�s all�g�) si on s'adresse
> � une base de donn�es orient�e objet.
>
Ok, donc c'est bien �a.
Je ne demanderai pas ce qu'est une base de donn�es orient�e objet, parce
que je vais finir par m'y perdre :)
>
> Avec un peu de recul, je dirais qu'il y a un malentendu � propos des
> frameworks (ou cadriciels, pour les acad�miciens scrupuleux).
> Ceux-ci, quelque soit le langage, semblent plut�t destin�s � construire
> des applications lourdes, comme celles d�velopp�es par des �diteurs,
> open source ou pas (par exemple un CMS bas� sur Zend Framework).
> Dans ce contexte, il est n�cessaire d'avoir une architecture modulaire
> tr�s pouss�e et une grande robustesse du code, ce qui justifie l'emploi
> de tels outils et la tol�rance en regard de leurs co�ts d'appropriation
> et d'exploitation (lourdeur, lenteur, apprentissage, personnalisation).
>
Pourquoi dans ce cas ne pas utiliser des CMF (Content Management
Framework) comme Drupal et surtout modx ?
> En dehors de ces cas, et sp�cifiquement pour PHP, je conseillerais deux
> solutions :
> 1. Classiquement, pour des petits projets, peu �volutifs et non
> modularis�s, ne pas oublier que PHP est d�j� en lui-m�me un syst�me de
> templates. Donc, juste s�parer la partie "applicative" (PHP, objet ou
> pas) de la pr�sentation (HTML + quelques "echo", boucles et tests PHP).
> 2. Pour des projets moyens, mais �volutifs et modularis�s, construire
> son propre framework all�g�. Un MVC en POO peut �tre une bonne id�e dans
> ce cas, sans rien exag�rer dans son architecture (pas d'usine � gaz).
>
C'est ce que je fais en partie, mais comme je le disais, je souhaitais
me reposer sur un framework pour am�liorer ma productivit� et la qualit�
du code (�galement la s�curit� de l'appli).
Par exemple, l� j'ai un module membre � faire. On en voit partout. La
base n'est vraiment pas compliqu� � faire mais si on doit parfaitement
g�rer les sessions, les autorisations et qu'en plus l'inscription doit
se faire avec r�ponse � un mail, c'est d�j� plus compliqu�.
Je l'ai d�j� fait mais forc�ment pas tr�s bien, vu mon niveau et dans
tous les cas beaucoup moins bien que si �a avait �t� fait par des
d�veloppeurs confirm�s.
Idem pour le CRUD. Etc.
Quant au MVC, je n'en voyais jusqu'� pr�sent pas trop l'int�r�t pour moi
mais avec des sites multilangues et l'optimisation pour le
r�f�rencement, ce serait utile.
Merci pour ta r�ponse.
Olivier Masson
> Olivier Masson a �crit :
>> Bonjour,
>>
>> Je continue mon apprentissage actif avec la lecture de "PHP5 avanc�"
>> qui est un peu creux, comme de nombreux livres de ce type,
>
> s/de nombreux/la grande majorit�/
>
>> mais bon, �a parle un peu objet, c'est d�j� �a.
>
> Je pense qu'il y a plus int�ressant comme litt�rature sur l'OO...
>
Mais qui ne parlent pas de PHP (tu me diras, c'est normal, puisque
pnepulo - on va abr�ger � partie de maintenant pour dire "PHP n'est pas
un langage objet -)...
Pourquoi m'obstiner avec PHP ? D'autant que Python n'est pas bien
compliqu�. Ruby je ne connais pas. Est-ce que PHP6 prend davantage un
chemin OO o� poursuit-on le chemin hybride ?
Mais un langage purement objet est-il finalement plus adapt� au web ?
En fait je me fous d'utiliser PHP, Python ou Ruby, coder en objet ou
proc�durale. Je cherche la rapidit� de d�veloppement et la facilit� de
maintenance ; pour la performance, vu les machines actuelles, �a semble
finalement secondaire.
> L'int�r�t effectif d�pend du type d'application, du langage et de la
> techno (server page ou long running process), de l'ORM lui-m�me... Dans
> Django (ORM sp�cifique) ou Pylons (SQLAlchemy), �a fonctionne plut�t
> bien. En PHP, ceux que j'ai vu passer personnellement �taient cod�s avec
> les pieds et pr�sentaient plus d'inconv�nient que d'avantages - mais
> honn�tement je n'en ai pas essay� tant que �a. A vrai dire, je ne pense
> pas que la techno PHP (langage proc�dural avec un mod�le objet rikiki,
> mod�le d'ex�cution server page avec reconstruction du "monde" entier �
> chaque requ�te HTTP, etc) se pr�te vraiment � cette approche (mon humble
> avis, hein...).
>
Django c'est un framework Python. C'est un peu le bordel quand m�me (pas
Django, mais ces interp�n�trations).
Doctrine, il sent des pieds comme ORM ?
>
> Hem... Y a a boire et � manger. Et certains trucs dont, quand tu regarde
> le code, tu te dis que tu es probablement trop modeste, et qu'il y a
> nettement plus incomp�tent que toi.
D�s que je vois une class avec plein de choses magnifiques (final,
abstract, extends, protected, des doubles underscore...), j'estime que
le mec � un skill level (je vais me faire censurer par Olivier ;)) de folie.
Je commence � relativiser en me disant que ce sont surtout des gamins
qui ont bien appris leur cours et font la m�me chose en PHP qu'on leur a
appris en C++. Ce qui est surement bien, en partie.
Je dis �a apr�s ce que tu affirmes ainsi que d'autres, mais �galement en
regardant le code de Drupal (peut-�tre pas un ref pour toi mais moi oui)
qui n'utilise semble-t-il pas du tout la POO... sauf en JS (normal).
> "lourdeur" dans quel sens ? Complexit�, ou mauvaises performances ?
Comme PEAR : l'obligation de te trimballer la pelle m�canique pour
planter ton pied de tomate.
Utiliser Symfony pour un petit site, �a me semble �tre du m�me acabit
que tous ces cr�ateurs de site qui utilisent Joomla pour le site d'un
artisan qui va faire 300 visites/mois : d�mesur�.
> Ca d�pend de la politique du projet - certains essayent d'�tre assez
> conservateurs (et donc de rester aussi compatibles que possible d'une
> version � une autre, et de bien documenter les rares incompatibilit�s),
> d'autres s'en fiche royalement. Dans le premier cas, c'est comme avec
> n'importe quel outil, une fois le "premier apprentissage" effectu�,
> suivre les �volutions est assez facile, � condition de "pratiquer"
> l'outil de fa�on r�guli�re et de suivre __effectivement__ les
> �volutions. Dans le second cas, bin, le mieux est probablement d'�viter
> l'outil !-)
Bon, va falloir choisir consciencieusement...
Au final je me rends compte que je veux faire comme les autres. Ce qui
est loin d'�tre dans mes habitudes, mais comme je me dis qu'un jour ou
l'autre, je vais finir par �tre salari� (nooooooooon !), faut que je
m'adapte � la demande. Et en province, on a pas trop le choix.
D'un autre c�t�, comme je disais, je cherche �galement � d�velopper plus
intelligemment (rapidement, correctement...)
Est-ce compatible ? Il faut que je trouve cette compatibilit�.
Bruno Desthuilliers
> Bruno Desthuilliers a �crit :
>> Olivier Masson a �crit :
>>> Bonjour,
>>>
>>> Je continue mon apprentissage actif avec la lecture de "PHP5 avanc�"
>>> qui est un peu creux, comme de nombreux livres de ce type,
>>
>> s/de nombreux/la grande majorit�/
>>
>>> mais bon, �a parle un peu objet, c'est d�j� �a.
>>
>> Je pense qu'il y a plus int�ressant comme litt�rature sur l'OO...
>>
>
> Mais qui ne parlent pas de PHP (tu me diras, c'est normal, puisque
> pnepulo - on va abr�ger � partie de maintenant pour dire "PHP n'est pas
> un langage objet -)...
C++ n'est pas "purement" objet, loin s'en faut, et il est pourtant tr�s
pr�sent dans la litt�rature objet.
Ce que je voulais dire est qu'il y a deux aspects dans l'OO : la
"th�orie g�n�rale" (je devrais mettre �a au pluriel, mais bon...), et
les impl�mentations sp�cifiques (mod�les objet des diff�rents langages).
Le plus important � comprendre en OO se trouve dans la partie "th�orie
g�n�rale". Apr�s, selon l'impl�mentation, certaines �l�ments th�oriques
auront plus ou moins de pertinence, mais c'est un autre troll^d�bat.
> Pourquoi m'obstiner avec PHP ? D'autant que Python n'est pas bien
> compliqu�.
Python est effectivement relativement accessible - la barri�re d'entr�e
n'est pas tr�s haute, et la coh�rence de l'ensemble (pas parfaite, mais
incomparablement sup�rieure � celle de PHP) aide beaucoup.
Par contre, quand tu commence � entrer dans les d�tails, tu t'aper�ois
que le mod�le objet est _loin_ d'�tre simpliste - et permet des choses
dont tu ne r�verais m�me pas si tu ne connais que le mod�le objet de PHP.
> Ruby je ne connais pas.
On est toujours dans la m�me cours - langage OO tr�s dynamique -, et la
syntaxe ressemble � premi�re vue � celle de Python. Le mod�le objet et
la "philosophie" sont par contre totalement diff�rents - mais offrent au
final � peu pr�s les m�mes possibilit�s au point de vue expressivit� et
dynamisme.
Point de vue impl�mentation et biblioth�ques dispos, Python a - pour le
moment - l'avantage de l'ant�riorit�.
> Est-ce que PHP6 prend davantage un
> chemin OO o� poursuit-on le chemin hybride ?
Ca reste un bricolage incoh�rent de toutes fa�ons.
> Mais un langage purement objet est-il finalement plus adapt� au web ?
Ni plus ni moins qu'un langage purement proc�dural ou purement
fonctionnel ou n'importe quel hybride. Ce qui compte est:
- l'ad�quation entre le mod�le d'ex�cution et l'approche utilis�e
- l'ad�quation entre l'approche utilis�e et la fa�on dont tu te
repr�sente le monde !-)
Par contre, il est clair que, compar�e � du proc�dural pur et dur,
l'approche objet peut tr�s nettement favoriser la r�utilisabilit� - ce
n'est pas un hasard s'il y a plus frameworks OO que de frameworks
proc�duraux. Non pas que �a r�duise la complexit�, mais �a aide � la g�rer.
Apr�s, c'est s�r qu'on peut aussi, avec un peu de cr�ativit�, concevoir
un framework PHP tr�s simple et compl�tement proc�dural (j'y ai d�j�
r�fl�chi, plus d'une fois). Je crains par contre que �a n'ait pas la
souplesse et la maintenabilit� d'un bon framework OO.
> En fait je me fous d'utiliser PHP, Python ou Ruby,
Mmm... pas moi, en fait. Quand tu a l'habitude de langages comme Python
ou Ruby, PHP fait figure de punition.
> coder en objet ou
> proc�durale. Je cherche la rapidit� de d�veloppement et la facilit� de
> maintenance ;
L'une et l'autre d�pendent en partie de la complexit� du projet et de
ses besoins en �volutivit�.
> pour la performance, vu les machines actuelles, �a semble
> finalement secondaire.
Pas tant que �a - regarde les probl�mes de Twitter !-)
Mais sans aller des ces cas "rares", les probl�mes de performance - et
surtout les probl�mes de capacit� � tenir la mont� en charge, mais �a se
rejoint en partie - sont � prendre en compte.
> Doctrine, il sent des pieds comme ORM ?
connait pas.
>>
>> Hem... Y a a boire et � manger. Et certains trucs dont, quand tu
>> regarde le code, tu te dis que tu es probablement trop modeste, et
>> qu'il y a nettement plus incomp�tent que toi.
>
> D�s que je vois une class avec plein de choses magnifiques (final,
> abstract, extends, protected, des doubles underscore...), j'estime que
> le mec � un skill level (je vais me faire censurer par Olivier ;)) de
> folie.
Mouarf. Si je te montrais ce � quoi je m'amuse en Python (m�taclasses,
surcharge de la r�solution d'attributs etc), tu me prendrais pour un
dieu alors !-)
Personnellement, ce qui m'impressione le plus, c'est le code tellement
simple et �vident qu'il n'y a m�me pas � se servir de ses neurones pour
tout piger tout de suite. Ca a pas l'air, mais c'est probablement le
plus difficile � atteindre.
> Je commence � relativiser en me disant que ce sont surtout des gamins
> qui ont bien appris leur cours et font la m�me chose en PHP qu'on leur a
> appris en C++. Ce qui est surement bien, en partie.
Mmm...
> Je dis �a apr�s ce que tu affirmes ainsi que d'autres, mais �galement en
> regardant le code de Drupal (peut-�tre pas un ref pour toi mais moi oui)
Le code de drupal - ce que j'en ai vu quand j'ai du mettre les mains
dans le cambouis, et ce pour des choses tellement triviales que �a
n'aurait jamais d� n�cessiter de devoir mettre les mains dans le
cambouis - est AMHA une pure horreur. Et ne parlons pas de la
"structure" de la base de donn�es :(
>
>> "lourdeur" dans quel sens ? Complexit�, ou mauvaises performances ?
>
> Comme PEAR : l'obligation de te trimballer la pelle m�canique pour
> planter ton pied de tomate.
Si tu savais ce que je pense de PEAR...
> Utiliser Symfony pour un petit site, �a me semble �tre du m�me acabit
> que tous ces cr�ateurs de site qui utilisent Joomla pour le site d'un
> artisan qui va faire 300 visites/mois : d�mesur�.
D�mesur� si tu dois apprendre tout le framework (ou tout le CMS)
uniquement pour �a. Quand tu fais des dizaines de site par an avec ces
outils, tu va *beaucoup* plus vite comme �a qu'en r�inventant la roue �
chaque projet. C'est d'ailleurs souvent comme �a que naissent les
framework : en factorisant, petit � petit, tous les trucs r�currents
d'un projet � l'autre.
> Au final je me rends compte que je veux faire comme les autres. Ce qui
> est loin d'�tre dans mes habitudes, mais comme je me dis qu'un jour ou
> l'autre, je vais finir par �tre salari� (nooooooooon !), faut que je
> m'adapte � la demande. Et en province, on a pas trop le choix.
> D'un autre c�t�, comme je disais, je cherche �galement � d�velopper plus
> intelligemment (rapidement, correctement...)
> Est-ce compatible ?
Plus ou moins !-)
> Il faut que je trouve cette compatibilit�.
L'essentiel est d'avoir des bases solides - protocole HTTP, DOM, mod�le
relationnel etc, plus si possible une bonne compr�hension - au moins
g�n�rale - de l'OO et de la PF. Coder une appli en pur CGI peut �tre
tr�s instructif, et d�velopper son propre framework aussi - m�me s'il
est totalement bancal, �a permet de mieux comprendre les choix de
conception des autres, et aussi de mieux juger de la pertinence de ces
choix.
Pour ce qui est des "outils du march�", tu ne coupera pas � PHP
(proc�dural ET objet), ni � un "gros" CMS (genre Drupal ou Joomla). Un
framework comme Symphony serait certainement un plus. Apr�s, une bonne
connaissance de Python+Django ou Ruby+Rails peut faire une grande
diff�rence. Mais en tout �tat de cause, si tu n'a pas les bases, tu va
gal�rer quelque soit l'outil.
Bruno Desthuilliers
> Je ne demanderai pas ce qu'est une base de donn�es orient�e objet, parce
> que je vais finir par m'y perdre :)
D'autant que la d�finition n'est pas tr�s dure � trouver.
>>
>> Avec un peu de recul, je dirais qu'il y a un malentendu � propos des
>> frameworks (ou cadriciels, pour les acad�miciens scrupuleux).
>> Ceux-ci, quelque soit le langage, semblent plut�t destin�s �
>> construire des applications lourdes,
Pas d'accord. M�me pour des applis tr�s simples, un bon framework permet
de se simplifier �norm�ment la vie.
>> comme celles d�velopp�es par des
>> �diteurs, open source ou pas (par exemple un CMS bas� sur Zend
>> Framework).
>> Dans ce contexte, il est n�cessaire d'avoir une architecture modulaire
>> tr�s pouss�e et une grande robustesse du code, ce qui justifie
>> l'emploi de tels outils et la tol�rance en regard de leurs co�ts
>> d'appropriation et d'exploitation (lourdeur, lenteur,
Tu parles des framework PHP, l� ?-) Parce que Django, c'est pas
exactement "lent et lourd".
>> apprentissage,
>> personnalisation).
>>
>
> Pourquoi dans ce cas ne pas utiliser des CMF (Content Management
> Framework) comme Drupal et surtout modx ?
Parce que ces "CMF" imposent des r�gles et des fonctionnement bien plus
complexes et contraignants - et tr�s souvent totalement inadapt�es au
besoin - qu'un framework applicatif.
(snip)
> Quant au MVC, je n'en voyais jusqu'� pr�sent pas trop l'int�r�t pour moi
> mais avec des sites multilangues et l'optimisation pour le
> r�f�rencement, ce serait utile.
L'int�r�t du (soi-disant) "MVC" [1] est surtout de s�parer autant que
possibles les responsabilit�s:
- gestion des donn�es et r�gles m�tier ("mod�le")
- pr�sentation ("vue")
- gestion des interactions utilisateur ("contr�leur")
Cette s�paration facilite grandement la maintenabilit� et l'�volutivit�,
en comparaison du code spaghetti qu'on trouve typiquement dans du PHP
"old-school".
Accessoirement, un framework objet complexe n'est en rien n�cessaire �
la mise en oeuvre d'un tel mod�le. Ca peut se faire tr�s simplement en
restant dans le mod�le server page / proc�dural d'origine de PHP - �
condition d'�tre un peu disciplin�...
[1] utiliser le terme MVC pour d�crire les frameworks web auquel ce
terme est accol� est un abus de langage pur et simple - le MVC n'a de
sens que dans un GUI "classique". Mais bon, passons...
Olivier Masson
> Mouarf. Si je te montrais ce � quoi je m'amuse en Python (m�taclasses,
> surcharge de la r�solution d'attributs etc), tu me prendrais pour un
> dieu alors !-)
>
Je suis souvent �pat� par ce que je ne maitrise pas dans mon secteur
d'activit�. Le probl�me, c'est qu'une fois que je comprends, je suis
terriblement de�u :)
> Personnellement, ce qui m'impressione le plus, c'est le code tellement
> simple et �vident qu'il n'y a m�me pas � se servir de ses neurones pour
> tout piger tout de suite. Ca a pas l'air, mais c'est probablement le
> plus difficile � atteindre.
>
Tiens, pourtant c'est l'impression que j'avais de Drupal, que tu ne
sembles pas vraiment aimer.
> D�mesur� si tu dois apprendre tout le framework (ou tout le CMS)
> uniquement pour �a. Quand tu fais des dizaines de site par an avec ces
> outils, tu va *beaucoup* plus vite comme �a qu'en r�inventant la roue �
> chaque projet. C'est d'ailleurs souvent comme �a que naissent les
> framework : en factorisant, petit � petit, tous les trucs r�currents
> d'un projet � l'autre.
>
En fait je parlais toujours de d�mesure l'outil par rapport au chantier.
Pour le reste, je suis bien convaincu que l'utilisation augmente
nettement la productivit�.
>
> L'essentiel est d'avoir des bases solides - protocole HTTP, DOM, mod�le
> relationnel etc, plus si possible une bonne compr�hension - au moins
> g�n�rale - de l'OO et de la PF. Coder une appli en pur CGI peut �tre
> tr�s instructif, et d�velopper son propre framework aussi - m�me s'il
> est totalement bancal, �a permet de mieux comprendre les choix de
> conception des autres, et aussi de mieux juger de la pertinence de ces
> choix.
>
> Pour ce qui est des "outils du march�", tu ne coupera pas � PHP
> (proc�dural ET objet), ni � un "gros" CMS (genre Drupal ou Joomla). Un
> framework comme Symphony serait certainement un plus. Apr�s, une bonne
> connaissance de Python+Django ou Ruby+Rails peut faire une grande
> diff�rence. Mais en tout �tat de cause, si tu n'a pas les bases, tu va
> gal�rer quelque soit l'outil.
Pas �vident de passer d'un profil admin s&r � web.
Mais je ne cherche pas � �tre d�veloppeur (mon Dieu non ! J'ai �t�
horrifi� chaque jour o� j'allais faire mon audit de s�curit� dans cette
boite avec tous ces dev derri�re leur(s) �cran(s) qui ne parlent que de
�a !) mais parfaire mon profil de webmaster pour tendre vers chef de projet.
Merci encore une fois pour tous ces �claircissements.
Olivier Miakinen
Le 19/11/2009 10:21, Olivier Masson rￜpondait ￜ Bruno Desthuilliers :
>>
>> Je pense qu'il y a plus intï¿œressant comme littï¿œrature sur l'OO...
>
> Mais qui ne parlent pas de PHP [...]
>
> Pourquoi m'obstiner avec PHP ? D'autant que Python n'est pas bien
> compliquￜ. Ruby je ne connais pas. Est-ce que PHP6 prend davantage un
> chemin OO oￜ poursuit-on le chemin hybride ?
>
> [...]
> En fait je me fous d'utiliser PHP, Python ou Ruby, coder en objet ou
> procï¿œdural. [...]
>
> Django c'est un framework Python. [...]
>
> [...] PHP [...] C++ [...] Drupal [...] POO [...] JS [...]
Dans toute cette discussion, il me semble que tu n'es pas vraiment fixￜ
sur PHP (et surtout que tu n'as pas de question propre ￜ PHP). Je me
demande du coup si tu as bien choisi le meilleur forum pour en parler.
Par ailleurs, tu sembles plutï¿œt te concentrer vers le dï¿œveloppement web
(ce qui, je le rappelle, n'est pas la seule utilisation de PHP). Tout
cela me fait dire que tu aurais peut-ï¿œtre de meilleures rï¿œponses dans le
groupe consacrￜ au dￜveloppement web, f.c.i.w.auteurs.
Jdï¿œjdr...
--
Olivier Miakinen
Olivier Masson
> Dans toute cette discussion, il me semble que tu n'es pas vraiment fixￜ
> sur PHP (et surtout que tu n'as pas de question propre ￜ PHP). Je me
> demande du coup si tu as bien choisi le meilleur forum pour en parler.
Je suis fixￜ sur PHP dans la mesure oￜ je l'utilise depuis quelques annￜes.
>
> Par ailleurs, tu sembles plutï¿œt te concentrer vers le dï¿œveloppement web
> (ce qui, je le rappelle, n'est pas la seule utilisation de PHP). Tout
> cela me fait dire que tu aurais peut-ï¿œtre de meilleures rï¿œponses dans le
> groupe consacrￜ au dￜveloppement web, f.c.i.w.auteurs.
>
Mon but n'est pas de savoir quel langage utiliser. J'ai dￜjￜ entendu
mille fois que Python ï¿œtait super - c'est surement vrai -, idem pour
Ruby (lￜ, effet "je suis un rebelle, un marginal, php c'est caca, etc.").
Si j'avais ￜcoutￜ tous ces chants de sirￜne, gamin j'aurais fait de
l'assembleur !
Idem pour les distrib linux, idem mï¿œme pour le shell (quoique ï¿œa,
maintenant, ￜ peu prￜs tout le monde est d'accord) !
Je vais peut-ï¿œtre tenter Python, si j'ai le temps. Mais pour l'instant,
c'est PHP. Et peut-ï¿œtre Symfony.
Alain BARTHE
>
> Le 19/11/2009 10:21, Olivier Masson rￜpondait ￜ Bruno Desthuilliers :
>>> Je pense qu'il y a plus intï¿œressant comme littï¿œrature sur l'OO...
>> Mais qui ne parlent pas de PHP [...]
>>
>> Pourquoi m'obstiner avec PHP ? D'autant que Python n'est pas bien
>> compliquￜ. Ruby je ne connais pas. Est-ce que PHP6 prend davantage un
>> chemin OO oￜ poursuit-on le chemin hybride ?
>>
>> [...]
>> En fait je me fous d'utiliser PHP, Python ou Ruby, coder en objet ou
>> procï¿œdural. [...]
>>
>> Django c'est un framework Python. [...]
>>
>> [...] PHP [...] C++ [...] Drupal [...] POO [...] JS [...]
>
> Dans toute cette discussion, il me semble que tu n'es pas vraiment fixￜ
> sur PHP (et surtout que tu n'as pas de question propre ￜ PHP). Je me
> demande du coup si tu as bien choisi le meilleur forum pour en parler.
>
> Par ailleurs, tu sembles plutï¿œt te concentrer vers le dï¿œveloppement web
> (ce qui, je le rappelle, n'est pas la seule utilisation de PHP). Tout
C'est quoi les autres utilisations possibles de PHP ?
Olivier Miakinen
>
>> Dans toute cette discussion, il me semble que tu n'es pas vraiment fixￜ
>> sur PHP (et surtout que tu n'as pas de question propre ￜ PHP). Je me
>> demande du coup si tu as bien choisi le meilleur forum pour en parler.
>
> Je suis fixￜ sur PHP dans la mesure oￜ je l'utilise depuis quelques annￜes.
Ok. Il n'empï¿œche que tes questions -- et les rï¿œponses de Bruno --
tournent quand mï¿œme plus autour des frameworks et des techniques
de dï¿œveloppement qu'autour de PHP lui-mï¿œme. Mï¿œbon, tant que les
modï¿œrateurs le laissent passer... ;-)
Olivier Miakinen
> [Copie intï¿œgrale]
<http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html>, merci.
>> Par ailleurs, tu sembles plutï¿œt te concentrer vers le dï¿œveloppement web
>> (ce qui, je le rappelle, n'est pas la seule utilisation de PHP). Tout
>
> C'est quoi les autres utilisations possibles de PHP ?
Les mï¿œmes que perl, que les *sh (csh, ksh, bash, etc.), et que de
nombreux autres langages : faire des scripts en local sur sa machine.
Voir par exemple ceci (dￜsolￜ, c'est en anglais) :
<http://www.phpbuilder.com/columns/darrell20000319.php3>.
On y trouve par exemple le script suivant (oￜ l'utilisation de stdin
montre bien que ce script ne *pourrait* pas ￜtre utilisￜ derriￜre un
serveur web) :
----------------------------------------------------------------------
#!/usr/local/bin/php -q
<?php
function read() {
$fp=fopen("/dev/stdin", "r");
$input=fgets($fp, 255);
fclose($fp);
return $input;
}
print("What is your first name? ");
$first_name = read();
print("What is your last name? ");
$last_name = read();
print("\nHello, $first_name $last_name! Nice to meet you!\n");
?>
----------------------------------------------------------------------
Denis Beauregard
�crivait dans fr.comp.lang.php:
>Olivier Miakinen a �crit :
>>
>> Par ailleurs, tu sembles plut�t te concentrer vers le d�veloppement web
>> (ce qui, je le rappelle, n'est pas la seule utilisation de PHP). Tout
>
>C'est quoi les autres utilisations possibles de PHP ?
Dans les ann�es 1980, j'avais �crit un �diteur de texte en Fortran.
Donc, a priori, il est possible d'utiliser un langage informatique
pour faire autre chose que ce qu'il devrait faire.
PHP a �t� con�u en fonction du web, je pense que tout le monde sera
d'accord. Mais on peut s'en servir pour autre chose.
Par exemple, PHP peut ouvrir un fichier, lire des lignes de texte
tabul� (colonnes s�par�es par des tab) ou CSV, ins�rer ces lignes
dans une base de donn�es ou bien faire certaines op�rations avant
de placer le r�sultat dans un autre fichier. Ce n'est pas �
proprement parler du d�veloppement web, mais c'est une utilisation
possible.
De m�me, je pourrais faire une appli PHP qui extrait des donn�es d'une
base de donn�es, produit des pages web, puis je prendrais ces pages
web avec un copier-coller pour les placer dans un �diteur de texte
comme Open Office, et je pourrais faire du r�sultat un livre imprim�
sur papier. Encore une fois, ce n'est pas le but de PHP, mais c'est
une utilisation possible avec un autre but que de faire des pages
web comme objectif final. Personnellement, je fais un truc de ce
genre en C++, mais je pourrais tr�s bien le faire en PHP si je ne
savais pas programmer en C++ (qui est un langage compil�, donc
beaucoup plus rapide que le PHP interpr�t�).
Denis