Bonjour à tous,

Je viens devant vous aujourd'hui car j'ai plusieurs petite questions à vous poser. Tout d'abord quelles fonctionnalités doit contenir un bon framework PHP ? Par exemple pour moi la base d'un bon framework c'est le fait de pouvoir utiliser les mêmes méthodes du framework pour me connecter à différentes base de données.

Et une autre question peut être plus complexe, quelles est l'intérêt de faire de la programmation prototypée basée en PHP et si cela à grand intérêt pouvez vous me donnez un exemple de code pour me prouvez que c'est utile...

Enfin voilà j'ai présenté cela comme un questionnaire mais c'est les questions que je me suis posé cette nuit pendant que je dormais :p Alors si vous me répondez franchement pour que je puisse passer de bonne nuit


Bonne journée à bientôt

Thibaud

Salut,

Bonjour à tous,
Je viens devant vous aujourd'hui car j'ai plusieurs petite questions à vous poser. Tout d'abord [*]quelles fonctionnalités doit contenir un bon framework PHP ? Par exemple pour moi la base d'un bon framework c'est le fait de pouvoir utiliser les mêmes méthodes du framework pour me connecter à différentes base de données.
Et une autre question peut être plus complexe, [**]quelles est l'intérêt de faire de la programmation prototypée basée en PHP et si cela à grand intérêt pouvez vous me donnez un exemple de code pour me prouvez que c'est utile...
Enfin voilà j'ai présenté cela comme un questionnaire mais c'est les questions que je me suis posé cette nuit pendant que je dormais :p Alors si vous me répondez franchement pour que je puisse passer de bonne nuit
Bonne journée à bientôt
Thibaud

[*]Difficile question... Le framework idéal est celui qui est ouvert du point de vue code (lisible et
compréhensible) ainsi qu'ouvert pour y adjoindre des plugins et surtout sans surcharge; dont les libs
ne sont pas liées et dont les "include" sont gérées à la volée (contrairement à un include général sur tous
les modules - pas clair sur ce point lol) et ou le code ne ralentit en rien le serveur. ...et qu'il sépare
habillement code et view.

- Zend Framework (correspond très bien à cette demande)
- Hoa (j'adore son import à la sauce java)
- Y en à plein d'autres...

[**]par prototypé tu entends "objets" j'imagine. Perso... Euh... j'en fais (et rien que ca lol) je trouve
ca plus propre, chaque "machin" est rangé dans son tiroir et on sait ou on en est. C'est beaucoup
plus simple. Pour info j'ai commencé le php à l'époque ou les obj existaient pas et franchement je
vois la différence.

Voili, voilou

@+

PS1: Si je peux me permetre: ne pas confondre Moteurs de templates et autres CMS
PS2: C'est pas péjoratif mais mouts Templates/CMS tentent de donner une vision FW de leur app.
PS3: En même temps FW n'est àpres tout qu'un espace de travail...

Prenons alors l'exemple du framework Hoa moi aussi j'aime son import à la sauce JAVA

Mais je ne comprend pas l'espace de nom "Pom" et "Prototype"

Pouvez-vous me l'expliquer ? A quoi ces namespace servent-elles exactement ?

Merci de ta réponse en tous cas

Perso, je n 'utilise plus de framework Php. Bien que j'ai passé un moment sur symfony et cakePhp, je préfère la liberté.

Maintenant, je développe malheureusement (ou pas ) pas en équipe, et la dimension Php dans les derniers produits fond comme neige au soleil, donc j'ai certainement un regard biaisé.

En tout cas, le truc des différentes bases de données, c'est vraiment un défaut pour moi, car sous le prétexte d'offrir un accès facile à toute un pléthore de bases de données, on oblige le développeur à se restreindre à un petit choix bien spécifique. On le force. Exit les bases de données CouchDB et autres nouveautés intéressantes. De plus, on retire au développeur toute les spécificités des Db's, le forçant à utiliser un sous-ensemble de fonctionnalités. Un bel exemple étant la recherche full-text de mysql... je ne vois vraiment pas pourquoi on veut absolument concevoir des wrappers pour SQL alors que SQL à la base est déjà un langage hyper-simplifié et hyper-efficace pour interroger les Db's relationnelles. Tout ce qu'on veut construire dessus ou autour est forcément moins bien.

Je préfère nettement les Api's, qui permettent quelque part de se constituer un framework à la demande.

Quant à la programmation prototypée de Php, c'est encore une bâtardisation supplémentaire pour Php, qu'on force à faire des acrobaties juste par onanisme intellectuel. Y'en a même qui veulent lui faire faire du fonctionnel. Oui, tout est possible, oui, certains doivent y trouver leur compte, oui, ça permet une plateforme idéale d'apprentissage d'un autre paradigme, non, mélanger les paradigmes dans un même projet n'est pas toujours joli-joli, non, ce ne sera jamais aussi bien et beau que les langages pleinement prototypes ou fonctionnels. Enfin, j'aime toujours php (forcément), mais quand j'ai besoin de faire d'autres choses, j'utilise d'autres langages.

(J'entends par programmation prototypée la programmation orientée prototype, qui est une façon de faire de l'objet mais sans la présence de classes. Des essais ont étés fait en php, mais franchement, c'est assez inutile. On ne bâtardise pas vraiment php, le mot est un peu fort, mais les pirouettes nécessaires à son utilisation sont assez moches, puisque reposant sur une classe).

Salut,

Sujet à risques .. en effet la réponse à la question: qu'est ce qu'un bon framework , sera différente ou presque à chaque développeur ... ( sans compter ceux qui sont contre les fw )

Mais voici mon point de vue ,

Tout d'abord quelles fonctionnalités doit contenir un bon framework PHP ? Par exemple pour moi la base d'un bon framework c'est le fait de pouvoir utiliser les mêmes méthodes du framework pour me connecter à différentes base de données.

En fait , un framework , est un espace de travail , il est là pour structurer un projet et faciliter le développement en donnant une série d'outils , donc le framework idéal , sera celui qui te donnera les outils dont tu as besoin , et qui te simplifiera la vie . ( les gouts et les couleurs )

Car normalement , un fw , permet de concevoir un code :
- structuré
- Évolutif
- impersonnel ( D'autres développeurs pourrons faire evoluer le projet facilement )
- Sécurisé ( c'est un grand mot , disons que l'on a beau avoir les meilleurs lib , si l'utilisation est mauvaise ... rien ne change )

Apres , ce n'est pas parce que tout le monde utilise un fw , qu'il faut absolument en utiliser un .
Le temps d'apprentissage à l'utilisation d'un framework évolué , est parfois une perte de temps par rapport à la taille du projet .

Enfin voilà j'ai présenté cela comme un questionnaire mais c'est les questions que je me suis posé cette nuit pendant que je dormais :p Alors si vous me répondez franchement pour que je puisse passer de bonne nuit

Si tu commences à rêver d'éléphants bleu labelisé php , c'est mauvais .. va vite consulter :-p

A peluche ,

Ch.

Enfin voilà j'ai présenté cela comme un questionnaire mais c'est les questions que je me suis posé cette nuit pendant que je dormais :p Alors si vous me répondez franchement pour que je puisse passer de bonne nuit

Le fait de vouloir une réponse franche et tranchée, est certainement le meilleur moyen de devenir insomniaque et pour longtemps

Je rejoins Berzemus et stopher :

- Cela dépend de tes besoins.

- Ensuite l'utilisation d'un framework n'est pas toujours rentable notamment quand on développe en solo.

- Enfin si tu intègre une équipe de développement, le meilleur framework sera nécessairement celui qu'utilise ton équipe, tout en sachant que parfois certains sont fait maison...

On pourrait donc en conclure qu'un bon framework php est( celui qui s"adapte le plus à nos besoins. Bien sûr ne pas pouvoir inclure toute les bibliothèque en même temps est essentiel et même d'une évidence certaine.

Mais bon je ne sais toujours pas qu'elle est l'intérêt de faire des classes pour programmer en prototypée basée, comme dans HOA par exemple...


Bonne journée

L'extensibilité.

Par exemple, j'utilise Symfony. J'ai eu à modifier le comportement du cache de template. Rien de plus simple que d'hériter la classe dans mon projet, de modifier ce que je doit modifier, et les factories.
Alors que dans un code monolithique, j'aurais dû toucher le coeur en entier.

Bonjour,

Un framework (ossature une fois traduit) est un ensemble d'éléments qui permettent de développer rapidement une application, en y intégrant directement un certain nombre de mécanismes facilitant le développement et la maintenance :
- la sécurité (identification, gestion des droits, suppression des trous de sécurité classiques...)
- l'accès aux bases de données : quoi de plus pénible de devoir se palucher à la main les requêtes insert, update, alors que des outils permettent de les générer automatiquement ?
- la présentation des informations, au moyen de l'utilisation de gabarits (templates en anglais)
- ...

Les frameworks sont basés aujourd'hui sur le concept MVC, qui permet de séparer d'une part la logique applicative (le traitement des pages, les classes métiers...), la présentation (les gabarits d'affichage) et l'enchaînement des pages (identification, vérification des droits d'accès, exécution et chaînage des différents modules).

Les frameworks professionnels, comme symphony ou Zend framework, sont souvent complexes à mettre en place, en raison d'une phase d'apprentissage très forte ; c'est pourquoi ils sont surtout utilisés au sein d'équipes qui passent leur temps à développer. Il est relativement aisé de se fabriquer son propre framework (j'ai créé prototypephp, téléchargeable sur sourceforge), qui va assembler les différentes briques que l'on veut utiliser. Ainsi, prototpypephp intègre notamment ADODB et OBJETBDD pour l'accès aux données, SMARTY pour les gabarits, PHPGACL pour la gestion des droits, le tout organisé autour d'une page index.php qui gère l'enchaînement des pages (déclaration dans un fichier xml) : je gagne un temps fou lorsque j'ai besoin de développer une application professionnelle au sein de mon entreprise, mais il est vrai que comme c'est moi qui l'ait conçu, je sais comment il fonctionne...

Un des aspects intéressants de PHP, c'est sa capacité à intégrer aussi bien du langage de script que de la programmation objet. Souvent, les frameworks professionnels ne conservent que les aspects objet. Si cela présente de nombreux avantages, dans un certain nombre de cas, cela complexifie pas mal le développement, et n'est pas toujours un gage d'efficacité (une application procédurale sera toujours plus rapide lors de l'exécution qu'une application objet - je ne parle pas de la vitesse de développement).

Si ces aspects vous intéressent, je peux vous conseiller un ouvrage récent : "PHP : de l'analyse au développement d'une application professionnelle" (éditions ENI), qui traite de ces sujets.