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 ?
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.
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 ?
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.
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 ?
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.
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.
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).
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.
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).
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.
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).
Bonjour,
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 ?
Bonjour,
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 ?
Bonjour,
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 ?
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...
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...).
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.
"lourdeur" dans quel sens ? Complexité, ou mauvaises performances ?
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 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...
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...).
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.
"lourdeur" dans quel sens ? Complexité, ou mauvaises performances ?
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 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...
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...).
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.
"lourdeur" dans quel sens ? Complexité, ou mauvaises performances ?
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 !-)
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 ?
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.
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 ?
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.
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 ?
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.
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.
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)
"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é.
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 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.
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)
"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é.
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 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.
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)
"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é.
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é.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 [...]
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 [...]
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.
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.
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.
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...
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...
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...