Discussion :

[alex_vino]

A moins de les repasser en JSP.... Ho non, pire, en .NET. Ha ouais, le cauchemard, ça foût les chocottes.

Tu sembles t'y connaitre en JSP et surtout .Net Argumente s'il te plait.

[s4mk1ng]

Euh possible que il y ait une refonte du langage mais de la à abandonner entièrement le langage....

[Seb33300]

J'ai un peu développé en PHP il y a 10 ans, donc je ne connais rien à ce langage.
Mais est ce qu'on peut faire en PHP pur un back office dont les infos des fenêtres se mettent à jour instantanement (qui écoute sur un tube par ex ou qui se fait appeler)? Je ne parle pas d'ajax qui push toutes les 2 secondes pour rafraichir le navigateur.

Ce n'est pas vraiment un problème lié à PHP, puisque ça sera la même problématique pour n'importe quel autre langage web coté server.

Par contre coté client, grace au nouvelles fonctionalités HTML5 et notamment aux websocket, on devrait pouvoir arriver à quelque chose qui y ressemble.

[CocoDesBois]

Ce n'est pas vraiment un problème lié à PHP, puisque ça sera la même problématique pour n'importe quel autre langage web coté server.

Par contre coté client, grace au nouvelles fonctionalités HTML5 et notamment aux websocket, on devrait pouvoir arriver à quelque chose qui y ressemble.

Mon message (sorti de son contexte) ne concernait pas PHP en lui même, mais le fait que l'on puisse dire que PHP permettait de développer tous les back office, c'était un commentaire d'un précédent message.
Il existe des BO qui nécessite un client lourd, PHP ne couvre pas ce domaine, on ne peut donc pas l'utiliser pour développer tous les BO.
Et ce détail n'a aucun rapport avec le fait que PHP soit destiné à mourir ou pas.

[coolspot]

Oui mais le probleme c'est que si on ne peux

@coolspot: Et comme Ruby et .Net aussi, ce que je voulais dire c'est que dans certaines technologies ca coule de source mais en PHP pas toujours.

Ca coule de source à notre époque. Aujourd'hui en PHP je vois mal faire du from scratch avec tous les framework/CMS qui existe, tout comme JAVA.

A contrario là je suis sur un projet de merde avec ma SSII d'une appli JAVA datant de plus de 10 ans avec aucun framework. Ben je peut te dire que niveau qualité de code ou performance c'est du niveau PHP3 quoi.

Bref ce que je veut dire c'est que la réputation du PHP = caca c'est un mythe historique qui n'est absolument plus vrai de nos jours.

[Invité]

Ca coule de source à notre époque. Aujourd'hui en PHP je vois mal faire du from scratch avec tous les framework/CMS qui existe, tout comme JAVA.

A contrario là je suis sur un projet de merde avec ma SSII d'une appli JAVA datant de plus de 10 ans avec aucun framework. Ben je peut te dire que niveau qualité de code ou performance c'est du niveau PHP3 quoi.

Bref ce que je veut dire c'est que la réputation du PHP = caca c'est un mythe historique qui n'est absolument plus vrai de nos jours.

Oui c'est vrai la réputation est entaché car il y'a beaucoup de développeurs débutants qui n'ont pas de code structuré MVC par exemple. Du coup la réputation baisse, cependant pour débuter c'est parfait : je n'ai jamais vu quelqu'un débuter dans le Web avec du Spring, Hibernate

[alex_vino]

je n'ai jamais vu quelqu'un débuter dans le Web avec du Spring, Hibernate

Si ton entreprise utilise cela tu n'a pas vraiment le choix si?
Ou je bosse on a tous une architecture a respecter, et on utilise tous NHibernate. Comme beaucoup d'entreprises on a nos Framework internes, ce qui rend l'apprentissage souvent plus facile et dans le cas de NHibernate son utilisation transparente pour le dévelopeur.

[Abdellah2010]

Je connais pas beaucoup de choses en php, une lecture linière du morceaux de code (un langage non compilé contrairement à ASP NET), non orienté objet au début de son parcours.

[ABCIWEB]

Je connais pas beaucoup de choses en php, une lecture linière du morceaux de code (un langage non compilé contrairement à ASP NET), non orienté objet au début de son parcours.

Tu ne connais pas php et c'est pour cela que tu en profite pour donner ton avis ? Normal que ça te fasse mal

[Neckara]

Bonjour,

Jun langage non compilé contrairement à ASP NET

ll est toujours possible de compiler un code écrit dans un langage interprété si on recherche plus de performances.
Je me demande d'ailleurs si ce n'est pas facebook qui compilait ses pages PHP (?).

[Gugelhupf]

Sans aller dans HipHop utilisé par Facebook, qui peut rappeler à quoi servent les outils APC (et OPcache pour PHP 5.5), inclus dans la plateforme PHP pour ceux qui ne connaissent pas le fonctionnement de PHP ?

[alex_vino]

ll est toujours possible de compiler un code écrit dans un langage interprété si on recherche plus de performances.
Je me demande d'ailleurs si ce n'est pas facebook qui compilait ses pages PHP (?).

Tout a fait, d'ailleurs ils en parle dans le lien que j'ai partagé dans un de mes précédent message (le diaporama sur Facebook). La performance n'est pas le seul critere de la compilation du code par Facebook, il y a de multiples avantages a faire cela.

[Invité]

Si ton entreprise utilise cela tu n'a pas vraiment le choix si?
Ou je bosse on a tous une architecture a respecter, et on utilise tous NHibernate. Comme beaucoup d'entreprises on a nos Framework internes, ce qui rend l'apprentissage souvent plus facile et dans le cas de NHibernate son utilisation transparente pour le dévelopeur.

Quelqu'un qui débute dans le développement Web chez soi en autodidacte n'ira, je pense, presque jamais voir du côté de JEE.

Les frameworks internes sont faciles si la personne maîtrise déjà JEE ^^

Je parle juste de la facilité d'aborder le langage pour débuter. Je trouve excellent que grâce à PHP il y'a pleins de curieux qui découvrent ce monde

[BPiero]

Mon message (sorti de son contexte) ne concernait pas PHP en lui même, mais le fait que l'on puisse dire que PHP permettait de développer tous les back office, c'était un commentaire d'un précédent message.
Il existe des BO qui nécessite un client lourd, PHP ne couvre pas ce domaine, on ne peut donc pas l'utiliser pour développer tous les BO.
Et ce détail n'a aucun rapport avec le fait que PHP soit destiné à mourir ou pas.

Au contraire, il répond exactement à ta question, on voit bien que Seb33300 connais bien ce type de problématique et que toi, tu poste n'imp sur un sujet auquel tu ne comprend strictement rien. La preuve est dans sa réponse: "une fenêtre qui se met à jour toute seule n'est pas un problème d'un langage serveur, c'est côté client que ça se joue". Toi tu réponds à ça un truc complètement à côté de la plaque. Va jouer dans le sandbox STP

[alex_vino]

Quelqu'un qui débute dans le développement Web chez soi en autodidacte n'ira, je pense, presque jamais voir du côté de JEE.

Les frameworks internes sont faciles si la personne maîtrise déjà JEE ^^

Je parle juste de la facilité d'aborder le langage pour débuter. Je trouve excellent que grâce à PHP il y'a pleins de curieux qui découvrent ce monde

Je parlais de personnes avec des diplomes en informatique et un minimum de base en programmation. Sauf erreur de ma part si tu es auto-didacte et ne sait pas faire un "if-else" alors tu ne risque pas d'etre embauché par une entreprise et aussi n'etre pas tres rentable pour toi meme, donc ta question ne se pose pas vraiment. Entre "découvrir" et "métier" il y a un gouffre. Je pense que tu fais plutot un hors-sujet par rapport au probleme.

[CocoDesBois]

Au contraire, il répond exactement à ta question, on voit bien que Seb33300 connais bien ce type de problématique et que toi, tu poste n'imp sur un sujet auquel tu ne comprend strictement rien. La preuve est dans sa réponse: "une fenêtre qui se met à jour toute seule n'est pas un problème d'un langage serveur, c'est côté client que ça se joue". Toi tu réponds à ça un truc complètement à côté de la plaque. Va jouer dans le sandbox STP

ça sert à rien de s'enerver et d'être insultant, encore une fois, je parle du fait d'affirmer qu'on peut developper tous les back office avec PHP. Relis mon post initiale et celui auquel je répondais.
Il y a des back office qu'un langage web ne peut pas réaliser, est ce que tu peux le concevoir ou c'est hors de ta portée, monsieur le développeur web...

[BPiero]

ça sert à rien de s'enerver et d'être insultant, encore une fois, je parle du fait d'affirmer qu'on peut developper tous les back office avec PHP. Relis mon post initiale et celui auquel je répondais.
Il y a des back office qu'un langage web ne peut pas réaliser, est ce que tu peux le concevoir ou c'est hors de ta portée, monsieur le développeur web...

Désolé je me suis un peu emporté, je relis tes messages
[...]
Ok donc tu dis qu'on peut pas faire de BO à 100% en php, perso la plupart de mes BO sont en 100% php (mais pas tous, il y a quand même des cas où ça n'est pas la meilleure solution, ce qui ne signifie pas que c'est impossible).
Par rapport à l'exemple que tu donnes, (le coup des fenêtres qui se mettent à jour toutes seules), je persiste à essayer de te faire comprendre que ça n'est pas du ressort du langage serveur, donc que php n'a rien à voir là dedans, comme le soulignait Seb. Ça dénote de ta pars un manque évident de compréhension d'un mécanisme de base de développement web, une partie de ton code est exécutée sur le serveur, et ensuite une autre partie est exécutée sur le client. En ce qui concerne tes fenêtres, c'est du côté client. Comme dis Seb tu devrai regarder du côté des websocket, il est aussi possible de développer qque chose de spécifique du style requête ajax toutes les 2s. Il existe néanmoins une possibilité d'implémenter une solution peu élégante en php et js: envoyer le tampon de sortie (ob_flush) puis envoyer l'exécution de ta fonction JS de MAJ de ta fenêtre en temps utile, reflusher etc...
Merci de rester humble sur les sujets que tu ne maîtrise pas.
BPiero

[CocoDesBois]

Désolé je me suis un peu emporté, je relis tes messages
[...]
Ok donc tu dis qu'on peut pas faire de BO à 100% en php, perso la plupart de mes BO sont en 100% php (mais pas tous, il y a quand même des cas où ça n'est pas la meilleure solution, ce qui ne signifie pas que c'est impossible).
Par rapport à l'exemple que tu donnes, (le coup des fenêtres qui se mettent à jour toutes seules), je persiste à essayer de te faire comprendre que ça n'est pas du ressort du langage serveur, donc que php n'a rien à voir là dedans, comme le soulignait Seb. Ça dénote de ta pars un manque évident de compréhension d'un mécanisme de base de développement web, une partie de ton code est exécutée sur le serveur, et ensuite une autre partie est exécutée sur le client. En ce qui concerne tes fenêtres, c'est du côté client. Comme dis Seb tu devrai regarder du côté des websocket, il est aussi possible de développer qque chose de spécifique du style requête ajax toutes les 2s. Il existe néanmoins une possibilité d'implémenter une solution peu élégante en php et js: envoyer le tampon de sortie (ob_flush) puis envoyer l'exécution de ta fonction JS de MAJ de ta fenêtre en temps utile, reflusher etc...
Merci de rester humble sur les sujets que tu ne maîtrise pas.
BPiero

J'ai maintenu pendant plusieurs années un site + back office en aspx + extjs, tous ça pour le refaire ex nihilo en asp.net et WPF coté back.
Oui, on peut tout faire avec un langage web + navigateur, on a de jolies fenetres qu'on peut redimensionner, ça donne l'impression de se rafraichir tout seul, une sorte d'ersatz de client lourd, mais au prix d'un navigateur ne parvenant pas à libérer sa mémoire qui fait des go en fait de journée, comme souvent c'est un outil de travail utilisé intensivement sur le poste client.
Moi je te parle de back office perfomant, de grid qui clignote dès que des objets changent quelques part sur le réseau et qui renvoit des messages en moins de temps possible, qui gère le mieux possible la concurence.
Ba la il faut une appli mutli threadé, des objets distribués, de la tuyauterie, de la mémoire cache niveau client. Et tout ça, ça occupe 10 fois moins de mémoire (et ça va plus vite en developpement au passage)

Après je te l'accorde, il y aura des évolutions (celles que tu cites), mais ça restera toujours une surcouche de navigateur qui certes conviendra à la grande majorité des B.O.

Certaines fois, on a pas le choix, le back office, ce sera via le navigateur, d'autre fois, on a le choix et la il faut voir au dela et c'est dommage de pas en profiter.

Quand tu dis "Il existe néanmoins une possibilité d'implémenter une solution peu élégante en php", ça s'appelle tordre (ou plutot ramener) le fonctionnel, les performance et le confort utilisateur par (à) son expertise technique (langage web).

[ulspider]

Pour les projets WEB, je ne vois pas trop l'intérêt de se lancer dans JAVA, sauf dans certains cas particulers où JAVA est très utilisé dans le SI de l'entreprise et encore ...

Après les "ingénieurs commerciaux" des SSII entre leur pensée et leur argumentation client...

Salut,

il y des frameworks puissants qui assurent à la fois la partie serveur et la partie client (HTML, CSS, JS et Ajax). On écrit du Java et du XHTML, pas plus !

Exemple d'un objet complexe :
Datatable lazyloadé

Eh bien essaye de faire la même chose en PHP/HTML/CSS/JS... tu vas t'amuser...

[coolspot]

J'ai maintenu pendant plusieurs années un site + back office en aspx + extjs, tous ça pour le refaire ex nihilo en asp.net et WPF coté back.
Oui, on peut tout faire avec un langage web + navigateur, on a de jolies fenetres qu'on peut redimensionner, ça donne l'impression de se rafraichir tout seul, une sorte d'ersatz de client lourd, mais au prix d'un navigateur ne parvenant pas à libérer sa mémoire qui fait des go en fait de journée, comme souvent c'est un outil de travail utilisé intensivement sur le poste client.

Ca c'est le cas effectivement si tu utilise une environnement archaique et complètement dépassé comme Windows XP (qui ne sait pas gérer la mémoire et a de grosse fuite mémoire) et une vieille version de navigateur comme Firefox 3.6.

La oui tu aura un truc immonde, mais bon en passant par les derniere version des navigateurs actuel et un système ne datant pas de la guerre 14 comme Xp mais plus un truc comme Windows 7,8 ou du Ubuntu 12.04/12.10. T'aura aucun problème.