Ton exemple ca s'appelle Datatables et c'est faisable très très facilement avec PHP/jQuery.
http://www.datatables.net/release-da...rver_side.html
Ton exemple ca s'appelle Datatables et c'est faisable très très facilement avec PHP/jQuery.
http://www.datatables.net/release-da...rver_side.html
Je suis d'accord pour les framework.
Par contre ton exemple doit etre assez facilement faisable en PHP, du moins c'est simple en .Net et de mes restes de connaissance en PHP il n'y a rien de bloquant et de bien sorcier. La plupart de tes actions sont des appels Ajax puis une mise en forme, en utilisant jQuery + en créant quelques fonctions serveur on y arrive sans trop d'embuches.
Apres n'oublie pas que tous les projets n'ont pas les meme attentes (perso je fait tres rarement de datagrid) et que chaque langage/technologie/framework a ses avantages/inconvénients.
@ulspider
Oui comme disent coolspot et alex_vino il n'est pas probant ton exemple. On fait ça depuis bien longtemps en php/ajax sans pour autant dire que c'est complexe. D'ailleurs j'ai fait ce même type d'exemple au début pour m'initier à jquery. Sans dire que j'ai été vite (exercice d'initiation), je peux dire au moins que je n'ai pas rencontré de difficulté particulière.
Et puis pour ceux qui veulent aller vite il y a des lib toutes faites, donc c'est vraiment pas un exemple qui rendra un développeur php béat d'admiration, ou alors juste le petit dernier qui vient à peine de découvrir ajax.
Il y a 25 ans, un développeur a dit "Cobol est destiné à mourir". On voit ce qu'il en est aujourd'hui - la bestiole bouge encore et les profils de cobolistes sont très recherchés.
Si les langages (a fortiori un aussi bien implanté que PHP) mouraient rapidement de leurs défauts, ça se saurait.
Certains ont tendance a mélanger les langages de programmation Web avec les autres, je ne suis pas tout a fait d'accord.
Certaines entreprises comme dans la Finance développent des applications qui doivent durer au minimum des dizaines d'années, c'est pourquoi meme si le langage disparait petit a petit ces entreprises continueront a rechercher des profils pour continuer a maintenir cette application.
Dans le Web cette notion de durée est toute autre, on développe généralement un service qui peux percer aujourd'hui mais qui demain sera peut-etre abandonner, pour un effet de mode par exemple ou une concurrence trop farouche. Avec l'évolution des technologies Web il faut toujours remettre en question son application et les clients n'hésitent pas toujours a tout remettre et meme changer le langage si nécessaire.
71% des serveurs webs dans le monde sont sur OS Linux, avec Apache comme serveur web, et PHP comme serveur de langage de scripts servant d'interface avec MariaDB, MySQL ou PostgreSQL.
Il travaille pour quelle entreprise ce gars ?
Désolé mais je parlais du framework Primefaces dans sa globalité. Jquery c'est très bas niveau, ça te fait pas des tableaux paginées, des rafraichissement JS coté serveur, des updates d'une sous partie de la page de ton interface à partir de ton code coté serveur.
Oui tu peux faire pareil mais il n'existe aucune bibliothèque qui regroupe autant de composants finaux (métier) en PHP quand Java.
En d'autres termes pour faire un datatable tu iras sur le site du projet X qui te propose cela. Ensuite si tu veux un arbre (pour représenter une arborescence de dossier) tu iras sur le projet Y (qui n'aura pas penser son système comme X, donc tu perdras beaucoup de temps à comprendre leur logique). Tu intégreras X et Y sur ton site à l'instant t.
En terme de maintenabilité tu devras suivre les projets X et Y (et oui, il faut assurer la maintenabilité et faire les maj des produits, c'est beaucoup plus difficile si l'on en a beaucoup....). Ensuite tu découvriras que le projet X n'est plus maintenu (le créateur abandonne le projet ou autre) et là tu devras retrouver un équivalent de X pour le remplacer...
Pour la partie client le PHP ça ressemble à du bricolage en allant chercher un bout de code JS à droite, un bout de code Jquery à gauche... Désolé pour des petits sites webs c'est peut être jouable, pour des applications qui durent dans le temps non
Par contre pour la partie serveur, PHP répond sensiblement au même problématique que Java avec des frameworks comme Zend, Symfony ou Laravel.
Tout à fait d'accord avec toi.
Personnellement c'est plutôt dans un cadre strict que je travaille. Quand j’entends parler de HTML5, CSS 3... eh bien je sais que ce n'est pas pour tout de suite. On ne prend que des produits robustes sur lesquelles il y aura du suivi.
@ulspider
Si tu veux comparer java à ajax/php c'est une autre histoire et un autre débat dans lequel je n'entrerai pas car je ne connais pas java. Et tel que tu en parles (php côté client...?) j'ai bien l'impression que de ton côté tu connais très peu php/ajax. Alors bon notre débat risquerait d'être très peu instructif.
C'est très confus tout ça. Dans quelle catégorie classes-tu des sites comme facebook ou wikipedia ?Pour la partie client le PHP ça ressemble à du bricolage en allant chercher un bout de code JS à droite, un bout de code Jquery à gauche... Désolé pour des petits sites webs c'est peut être jouable, pour des applications qui durent dans le temps non
Assez d'accord, si php n'évolue pas vers le multi thread, il va mourir. Aujourd'hui la puissance d'un serveur ce mesure au type de processeur et au nombre de coeurs : les évolutions du kernel linux sont bien en retard sur les nouvelles instructions, et quand on ne peut pas augmenter le nombre de thread utilisées dans son application, il ne reste plus qu'a passer à un autre language.
pthread est une avancée notable, mais il doit être implémenté sur une installation thread safe, qui n'est pas encore tout à fait stable, et qui est loin d'être le mode par défaut des installations de php sur les différentes distributions.
Par contre les fuites de mémoires on été largement réglées (il était temps).
Donc en gros, on attend et on croise les doigts.
Salut, je connais bien PHP puisque je développe énormément dessus à mes heures perdues. Ce que je voulais dire c'est qu'avec PHP pour développer la partie client (la partie VUE du modèle MVC), tu écrit du PHP (pour les itérations, les conditions...), du HTML, du CSS, du JS, du Jquery...
En Java, tu as la possibilité (si tu prends les bons frameworks) uniquement du java. Tout le code est généré en automatique. Donc je me disperse pas à faire plein de choses et je gagne clairement en productivité. Par contre le coup d'initialisation (le ticket d'entrée) est important.
Et pour ce qui est de facebook, wikipedia le fait qu'ils soient développés en PHP est historique (ils ont commencé petits, PHP s'y prête bien). Je ne suis pas sûr que ces sites referaient le même choix aujourd'hui.
JSF2 / Primefaces :
- ne remplace pas le CSS pour le design.
- nécessite de la recherche et une formation pour chaque composant.
- propose des modèles génériques très utiles mais ne correspond pas aux besoins plus spécifiques du cahier des charges (ex : tableau HTML dynamique en hauteur et largeur, auquel on peut ajouter des lignes au milieu, dont la colonne n°3 contient un indicateur qui dépend de la valeur de la colonne 1 et 4 lorsque l'utilisateur modifie le contenu textfield), après on stocke le tout en BDD... Ou peut-être que je me trompe et que je n'ai pas trouvé mon bonheur ?
Du coup même si tu fais du XHTML dans tes vues, et du Java coté serveur, tu seras obligé de connaître CSS (ou framework type LESS / Bootstrap) si tu veux avoir un joli site web et JavaScript/jQuery pour les cas particuliers.
Après je rejoins ton idée comme quoi certains vont piquer des trucs sur X et Y, que c'est pas documenté, qu'il est préférable d'utiliser des outils plus "standard" etc... mais des développeurs Java le font aussi malheureusement.
Aussi il y a tellement de facteurs qui entrent en jeu :
Productivité : tu la gagnes plus rapidement avec PHP, tu l'as plus tard en Java. Déjà pour connaitre les outils que tu cites, il faut forcément commencer avec le J2EE (oui j'ai pas dis JEE) à l'ancienne avec les HttpServlet et le routing/mapping du web.xml, puis comprendre le manque à gagner avec la gestion des formulaires et transfert de fichier, donc passer à JSF2, puis de nouveau changer son mode de développement et faire mieux avec les bean d'un coté, tes vues qui sont plus propres de l'autre... Tu me diras que oui tu finiras forcément par acquérir cela en PHP avec les outils actuels et c'est le cas, tu commences à apprendre l'orienté objet, te lancer dans Symfony avec le modèle MVC et faire du Smart/Twig dans les vues, tu as Hibernate en Java, Doctrine en PHP, tout fini par se rejoindre... Sauf que pour avoir tes premières page en PHP à tes débuts tu as pris moins de temps à obtenir un résultat et tu étais satisfait de tes efforts... Et puis le tout c'est que ça fonctionne.
Hébergement : Ensuite pour héberger ton site c'est moins pratique en Java, plus couteux (bon un tout petit peu moins avec les services actuels je crois).
Je n'ai pas compris pour la partie tu glisses tu déposes, et les pages xhtml toutes faites, mais avec Symfony2 pour créer ton projet (ses dossiers, mapping) ou pour les tables/entités il suffit de lancer la console :
Pièce jointe 116404
Pas une ligne de code PHP pour le "bean", pas une ligne de code SQL pour créer la table.
Après je ne dis pas que ce n'est pas inspiré de Java, ça l'est même très fortement car l'auteur du framework aurait été influencé par Spring.
Ce n'est pas ça que je voulais parler, je sais que ça se fait facilement et en java et en php, déjà netbeans te permet de ne pas lancer la console que du graphique, mais je te parle du côté client et contrôleur pouvoir générer des opérations CRUD(creation de nouveau , sélection, suppression, mise à jour, lister.) avec les contrôleurs, et les views toutes faites, c'est fini de répéter les mêmes opération classiques et ceci sans écrire la moindre code.
Comme indique cette image, c'est du primefaces, on a une génération de tout sans écrire la moindre code :
Je crois qu'on est complètement passé à côté du propos de Gunslinger. J'ai lu son article et il ne prétend pas que le langage PHP va mourir, mais que les scripts PHP doivent se terminer (die) dans un temps fini: 30 secondes, 3 minutes, ... PHP n'est pas prévu pour des scripts qui tournent en continu. C'est cela qu'il dit. C'est une mauvaise compréhension/traduction de prétendre qu'il dit que le langage PHP va mourir !! Cela dit, son titre "PHP is meant to die" était un titre provocateur et il a joué sur les mots !! Relisez l'article original avec cette optique de termination de scripts et vous verrez que ça colle parfaitement !!
Tu dois être le troisième a expliquer ça, mais on arrête pas les trolls aussi facilement, surtout le vendredi et quand c'est les modérateurs qui se chargent de les lancer.
Je n'ai aucune intention de troller, je suis développeur Symfony2 et Java (débutant JSF2, en apprentissage de JPA) donc je trouve cela intéressant de réunir nos connaissances.
Oui j'ai lu le sujet et les commentaires. On sait tous que PHP va mourir à la fin du script c'est pas nouveau (thread toussa), c'est un langage web on ne peut pas tout faire avec. Nous aurions pu parler d'un autre problème comme l'Unicode.
Personnellement je ne savais pas qu'avec JSF2 on pouvait créer des CRUD graphiques comme le montre la.lune
Mais d'après ce que je vois sur internet, ce n'est pas lié à JSF2 mais l'IDE Netbeans, vous connaissez un équivalent Eclipse ? Il existe aussi un CRUD léger intégré dans Symfony2, mais il pète pas la classe comme dans l'exemple du dessus, sinon ça ne m'étonnerait pas qu'il y ait un bundle équivalent version Symfony2.
Oui tu écris encore un peu de CSS mais ça reste très faible. Pour les composants, chaque composant est pensé de la même façon et l'on retrouve les mêmes attributs sur les balises XML des composants (id, styleClass, process, update, partialSubmit...). Et les IDE Java aident beaucoup puisqu'au survol de l'attribut cela t'explique ce que celui-ci fait.
Pour la mise à jour des indicateurs, Primefaces utilisent énormément AJAX et les traitements seront fait coté serveur. Tu peux utiliser les sélecteur CSS pour mettre à jour très finement une sous-partie de ta page. Exemple :
En appuyant sur le bouton, je soumet tous les champs input dans les panneaux (process="@(.ui-panel :input)"). La méthode savePerson est exécutée. Ensuite on rafraichit tous les panneaux (update="@(.ui-panel)") (on peut supposer que la méthode savePerson modifie le contenu des panneaux). J'utilise partialSubmit="true" pour forcer l'optimisation de la requête AJAX et diminuer la bande passante. Bref, difficile de faire aussi court. Et l'on peut faire la même chose sur un champ input avec l’événement onkeyup ou onchange
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8 <p:commandButton id="ajax" value="Ajax Submit" process="@(.ui-panel :input)" update="@(.ui-panel)" partialSubmit="true" action="#{bean.savePerson}" />
Bon j'ai peut être un peu dérivé du sujet mais de toute façon l'auteur aussi ^^
Je crois que vous n'avez pas bien compris le sens de l'article original,
Quand l'auteur dit "PHP is meant to die" ça ne veut pas dire que c'est le langage qui est destiné à mourir. Il parle du fait que le workflow de php c'est la lecture des entrées, le process de ces données, et une sortie vers le client pour ensuite mourir. Car oui un procssus PHP est destiné a mourir
Je suggère à ce que cette discussion soit supprimé, étant donné que ça ne parle pas du vif sujet de l’article originale, et ça constitue un grand troll jamais publié sur ce forum, à moins que ce forum soit destiné aussi aux trolls.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager