j'apprends php 2

Olivier Masson a écrit :

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

Pascal a écrit :

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

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 !-)

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

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

Olivier Masson a écrit :

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

Merci pour ta réponse.

Olivier Masson a écrit :

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 a écrit :

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.

Bonjour,

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 Miakinen a écrit :

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.

Olivier Miakinen a écrit :

Bonjour,

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 ?

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