Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Comparer l'objet de Javascript à PHP c'est assez déplacé, ne serais ce parce que PHP est un langage serveur et Javascript client ... A ce moment là on peut aussi parler de la portabilité de Javascript (langage interprété pourtant !) qui laisse extrêmement à désirer, contrairement à celle de PHP qui est parfaite.
Oui, ben en fait, c'est le site de Phalanger dont j'ai donné l'URLEnvoyé par viviboss
Lol, il y a Phalanger aussi, qui fait bcp parler de lui (incorporer sans changer une seule ligne PHP à .NET....)
Et M..... Tu m'as cassé
De toute les facons, on a beau dire les langages clients sont indopensables, tous comme ceux serveur : un bon exemple d'interaction entre les deux est AJAX.
JavaScript est totalement portable... La seule différence provient du << FrameWork >> du navigateur
l'interprète oui mais comme JS est toujours basé sur un support (navigateur) et que pas deux ne définissent les même objets de la même façon ça change pas grand chose
c'est comme si tu prennais la syntaxe C du et que tu change toutes les fonction de base pour ne garder que if then else function switch case break while et for
alors oui javascript est portable mais je n'ai encore jamais vu un prog écrit à 100% en js
il s'appuis toujours soit sur un navigateur ou un outil de wiget
bref comme tout langage ce qui fait qu'il est portable ou pas ce n'est pas sa syntaxe car il n'est pas bien difficile de créer un compilo ou un interprète mais bien la librairie de base qui va avec et en js ele est loin d'être portable.
l'objet document n'existe pas dans tous les interprètes et quant il existe il n'a pas les mêmes attributs pire lorsque dans deux implémentations la même méthode du même objet existe elle n'a pas toujours la même signature ou le même effet
ce n'est pas vraiment ce qu'on peut appeler de la portabilité.
encore une fois il n'y a pas à comparer. js est adapté au scripting php au développement dans l'un on manipule les objets d'un système dans l'autre on crée les objet dont on a besoin. et les deux ont leur avantage qui est u incovégnant dans le contexte de l'autre.
A+JYT
Perso le js j'y touche pas, je laisse des frameworks me le générer ^^
GWT, struts validator, rialto.
Ouais, mais le pb des frameworks c'est le poid, surtout si on n'utilise qu'une petite partie des fonctionnalités proposés....
lu all,
Je suis entrain de développer une application de gestion de client/fournisseurs et j'utilise php/MySQL, car étant gratuit, j'aurais bien pût développer plus facilement avec Visual Basic mais il est assez cher...
Et comme ont peut très bien développer une application en php/MySQL et ne rien débourser, alors pourquoi s'en priver
Seul élément à avoir sous la main : un serveur gratuit ( j'utilise wamp5) et des neuronnes prêt à chauffer.
On peut faire de superbe datagrid avec php et PEAR Datagrid et Dataobject et tout ça gratos, voir :Datagrid et Dataobject
Voilà pourquoi j'ai voter OUI pour le php.
Perso, je suis pas pour les frameworks. Comme dit Viviboss : C'est lourd et on n'utilise qu'un faible pourcentage. PHP n'est pas tellement fait pour travailler en framework. Il aurait fallut pouvoir le compiler dans une dll.
Personnellement, je vois pas l'avenir de PHP avec les types de framework actuelle.
Ouch ! C'est vraimment sujet à Troll ! Fallait dire : "Tout les frameworks sauf celui qu'utilise is_null" hahaha.
Tu as tout-à-fait raison : la meilleure optimisation pour un code lourd à executer est de simplement le programmer en C, que ce soit un framework ou quoi-que-ce-soit d'autre, il en sortira ton module .so ou .dll sous windoziehnx. D'ailleurs, on peut maintenant programmer des extensions et utiliser une interface object comme XMLReader, PDO ou SPL : c'est trop bien. Aussi, il faut admettre que SimpleTest ou PHPUnit sont indispensables pour écrire rapidement un maximum de test-unitaires.
Ensuite, je ne voie vraimment pas comment me passer de eZ components. Vous allez me dire que ce n'est pas un framework comme les autres puisqu'un peu à la PEAR, on utilise les composants qu'on veut comme on veut. Personnelement, c'est MVC et actions
Les composants qui me sont indispensables sont :
- Database : systême d'abstraction totale de base de données, permet au code et à l'installeur de tourner nativement sur Oracle, MySQL, SQLite et bien sûr la plus optimale : PostgreSQL
- PersistentObjects : il y a un parseur pour la base de données, qui génère des définitions d'objets persistents (1 par table). Ces définitions sont personnalisables, notamment pour les relations. Tout plein de fonctions sont disponnibles et c'est franchement indispensable pour du developpement agile.
- Template : C'est fonctionnel comme smarty, mais avec un temps d'execution incomparable, des fichiers compilés bien plus intelligents et propres, avec une syntaxe moins farfelue.
- Translation : C'est quand même pratique de pouvoir éditer ses fichiers de traduction avec QTLinguist. D'accord c'est du XML et c'est long à traiter. Mais il y a un systême de cache en tableaux PHP intégrés de toutes façons
Et mes petits composant perso, pour sortir des interfaces admins complêtes en quelques minutes (muahaha) :
- Form : une sorte de quickform en plus rapide, et utilisant SPL pour un confort d'usage incomparable. Utilise l'extension filter de PHP pour un filtrage d'input niveau C (d'ailleurs, je suppose que c'est parce que les composants en PHP étaient trop lents que Derick Rethans -alias M. Xdebug- a codé cette extension).
- PosForm : Un parseur de définitions d'objets persistents pour générer des instances de Form avec leurs éléments tout prêts à l'emploi, avec quelques bonus comme une méthode pour charger un élément dans le formulaire pour pré-remplir les champs, et une autre pour faire la même chose mais avec les relations
Quant tu dis qu'on en utilise qu'un faible pourcentage, c'est faux dans mon cas. Non, je n'ai pas fait de tests de couverture de code pour l'instant, mais j'étend la majorité des objets de eZ que j'utilise, je suppose qu'à la manière dont je le fait, j'exploite le framework au maximum.
Pour les frameworks comme cakePhp qui forcent à une structure sans laisser vraimment de liberté, je pense que tu as encore tout-à-fait raison !
Et franchement, coder la persistence des objets ainsi que leurs formulaires d'édition soi-même est une véritable corvée n'est-ce-pas ?
Editer les fichiers de languages passe encore, mais on est franchement mieux avec un bon GUI Open-Source
Le systême de template, d'accord c'est que de la frime
Quand je serais balèze en C, je passerai probablement 80% de mon temps à coder des extensions
Liens :
http://dico.developpez.com/html/2685...persistant.php
http://en.wikipedia.org/wiki/Object-relational_mapping (en)
http://ez.no/doc/components/view/lat...entObject.html (en)
http://www.lastcraft.com/ (en)
http://www.phpunit.de/pocket_guide/3.2/en/index.html (en)
http://php.net/filter
http://ez.no/doc/components/view/lat..._Database.html (en)
Mais intimenent, je pense que ruby à bien plus d'avenir dans le milieu des "programmeurs de l'extreme", mais c'est une autre histoire ... De toutes façons, j'ai encore quelques fonctionnalités de SPL et beaucoup de PHPUnit à travailler avant de faire 100% d'XP.
Au passage, je vous donne les deux meilleurs bouquins qui existent sur PHP5, il s'agit de :
PHP in action en anglais sortit en Juillet 2007, le meilleur bouquin selon moi
PHP Power Programming (moins balèze)
Deux bouquins incomparables avec le best-seller français : PHP avancé, qui n'est franchement pas avancé comparé aux deux autres.
A nous de lui donner un avenir!
PHP, dans sa version 6 (et en retro sur la version 5.3) intègre une notion de namespace. Il devient donc plus pro et plus facile de développer des vrais framefork.
Un vrais framework n'est pas un simple ajout de fonction catégorisé de plus ou moins haut niveau (Type L4G) ou un site intégrant une administration permettant la construction d'un autre site!. Un framework est un environnement utilisé pour développer des applications complètes (ex : java ou .net) intégrant les objets graphiques (windows, form, onglet, treeview, champ, bouton...).
Un framework intégrant PHP et Javascript permettrais réellement de concurrencer Flex ou les autres concept WEB2. Car, si on peut maintenant faire du WEB2 avec PHP, il faut avant tout du javascript et tous développer manuellement! (l'object javascript, le remote des events via AJAX et le traitement php)
Certains langages ont une avance déjà importante permettant de développer un WEB2 complet en wysiwyg : Matrix, EDI pour Flex... (ex : sur MATRIX, création de l'évènement onClick en ASP d'un bouton HTML. 'onClick' étant une fonction callback déclenché en remote via de l'AJAX). Delphi for php est un EDI qui fait presque ça! Il utilise Zend framework et des FW javascript comme Qooxdoo, mais pas un vrai FW complet qui permettrait d'utiliser uniquement PHP! ex :
$form = new framework::windows::form(800,640);
$form->borderStyle='3D';
$form->addControl(new framework::windows::compenent::champ('champ1',50,50,10,200));
$form->controls('champ1')->addHandle('onClick','champ1_onclick');
function champ1_onclick($sender){
//sur le onclick javascript, déclanchement AJAX et execution de la fonction PHP
}
Conclusion : Si on a pas au plus vite un framework PHP contenant du javascript, dhtml et css pour faire en sorte que PHP integre le WEB2, ce sont les autres langages qui prendront la main sur le WEB2 (l'avenir du web).
Je suis pas tellement sur que le "WEB2" soit vraiment le réelle avenir telle que nous le pensons. Web2, terme actuelle qui ne veut absolument rien dire et beaucoup commence à s'en rendre compte et font machine arrière concernant cette soit-disant technologie.
A l'heure actuelle, personne ne peut prédire l'avenir du WEB car il y a beaucoup de paramètres qui rentrent en jeux. Alors, oui une framework prenant un compte cette nouvelle "vision du web" pourquoi pas mais pour moi, une framework en php n'est pas adapté. Juste à cause du faite que PHP est un language interprété. Il aurait fallut qu'il puisse descendre au niveau des librairies. Ainsi, nous aurons des applications beaucoup plus rapide et facile à intégré, surtout s'il est intégré dans un IDE.
Personnellement, Web2 j'y crois qu'a moitier, j'attend de voir. Personnellement je voulais y mettre les pieds mais ...
Web2 ne veut rien dire en soi.
Mais c'est un ensemble de technologie.
Quand on dit qu'un langage est "Web2-ready", c'est qu'il possède un certain lot de technologie.
PHP n'est pas vraiment un exemple en terme de Web2 car il ne gère que très grossièrement un paquet de techno...
http://fr.wikipedia.org/wiki/Web_2
Pourquoi tu dis que PHP ne gère que grossièrement les technos Web2 ?
- CSS et XHTML, pas de besoin particulier pour l'intégrer
- AJAX, multiples frameworks en php, de toute facon ce n'est pas PHP qui gère a proprement parler ajax
- la syndication, c'est plus un concept qu'une techno, php permet d'en faire
- etiquetage, utilisation des url, je m'étends pas dessus, la encore c'est pas sorcier d'en faire
- webservice, c'était déjà possible en php4 avec des librairies externes sans trop se casser la tête mais php5 a directement intégré une extension SOAP.
Bref, PHP est un très bon exemple de langage Web2 Ready, puisqu'il est justement très orienté web. (Le web2 vient surtout de la logique que l'on va adopter et des bonnes pratiques utilisées).
Pour ce qui est d'un framework il en existe déjà de multiples et coté IDE idem. Par contre pour travailler en JAVA et Php, j'avoue ne pas retrouver le même confort sur les IDE en Php. En java si je caricature un peu, je fais de l'assemblage de techno. En php je code encore beaucoup (et j'avoue qu'aujourd'hui j'ai plus envie de coder).
Sur ce dernier point je suis entierement daccord. Il est vrai que coté IDE, il y a pas le même confort qu'avec les IDE Java et .NET . Néanmoins, Zend Studio avec PhpEd tente d'améliorer le niveau mais c'est une question de maturité et de temps. Le temps que les framework se stabilisent un peut.
http://fr.wikipedia.org/wiki/Web_2
Pourquoi tu dis que PHP ne gère que grossièrement les technos Web2 ?
- CSS et XHTML, pas de besoin particulier pour l'intégrer
- AJAX, multiples frameworks en php, de toute facon ce n'est pas PHP qui gère a proprement parler ajax
- la syndication, c'est plus un concept qu'une techno, php permet d'en faire
- etiquetage, utilisation des url, je m'étends pas dessus, la encore c'est pas sorcier d'en faire
- webservice, c'était déjà possible en php4 avec des librairies externes sans trop se casser la tête mais php5 a directement intégré une extension SOAP.
Bref, PHP est un très bon exemple de langage Web2 Ready, puisqu'il est justement très orienté web. (Le web2 vient surtout de la logique que l'on va adopter et des bonnes pratiques utilisées).
Pour ce qui est d'un framework il en existe déjà de multiples et coté IDE idem. Par contre pour travailler en JAVA et Php, j'avoue ne pas retrouver le même confort sur les IDE en Php. En java si je caricature un peu, je fais de l'assemblage de techno. En php je code encore beaucoup (et j'avoue qu'aujourd'hui j'ai plus envie de coder
Zend a justement intégré son framework dans leur IDE.
Je continue à penser que les FrameWork tel quel ne seront pas l'avenir, il faut pouvoir rapidement passer à des frameWork sous forme d'extension PHP. Pour des questions de gain de performance et stabilité.
Avec quelques règles en plus dans l'environnement objet sans le rendre strict et PHP pourra être au top.
C'est sur ce point-là que j'en avais quand je disais que PHP n'est pas vraiment Web2-Ready...En java si je caricature un peu, je fais de l'assemblage de techno. En php je code encore beaucoup (et j'avoue qu'aujourd'hui j'ai plus envie de coder
En ASP 2.0 (et plus encore en ASP 3.0, même si je n'en fais pas encore), la gérance de tout ce qui est Web2 dépasse très largement ce dont est capable PHP (non pas qu'on ne puisse pas le faire en PHP mais surtout, comme tu l'as soulevé, cela prend plus de temps)
Deplus ASP s'exécute plus vite que PHP (même Phalenger (PHP.NET) est plus rapide que PHP sur une machine équivalente)
J'aurais tendance a dire que le language est bien Web2-Ready mais que les outils ne sont pas suffisament connus.
En cherchant bien, il semble exister des IDE qui gère ajax par exemple :
http://www.riff.org/un_nouvel_ide_php_pour_ajax
Et Zend framework a des outils pour la génération de WSDL et ces autres fonctionnalités sont très sympathiques :
http://www.zend.com/fr/products/studio/features
Ca existe donc, mais il faut l'acheter et je n'ai donc pas testé.
De toute facon ne connaissant pas bien ASP je ne me permettrais pas de comparaison sur les outils en tout cas.
Quand a la vitesse d'execution, personnellement de ce que j'en ai vu elle me convient, j'avoue que ce n'est pas mon critère puisqu'elle est déjà suffisante. En tout cas ce critère arrive derrière la possibilité de trouver facilement des hébergeurs
Point en effet très intéressante à soulever.En tout cas ce critère arrive derrière la possibilité de trouver facilement des hébergeurs
PHP est plus répendu et a donc plus d'hébergeur le supportant (et donc plus d'hébergeurs gratuit, par la même occasion).
Sur ca, je ne discute pas, c'est un avantage évident de PHP.
D'un autre coté, c'est un faux problème les histoires d'hébergeurs.
En fait, tout dépend de qui utilise PHP. Il y a trois grand groupes d'utilisateurs de PHP.
- Les utilisateurs voulant faire un petit site dynamic. Généralement, ils se content d'un hebergeur simple de préférence gratuit. PHP4 avec Mysql 4 leurs suffit
- Les utilisateurs voulant monter un projet ambitieux specifiquement en PHP et Mysql. ça commence à aller dans le retranchement de PHP5 et Mysql. Cela commence à avoir des configurations un peut plus poussé. Rarement, ils vont dans les gratuits mais ne vont pas se ruiner dessus. Personnellement, je suis dans ce cas là et j'ai pris un serveur virtuel pour des questions de confort.
- Les entreprises ayant un gros projet monté en PHP ça varie d'un hebergeur serieux au serveur dédier.
Selon l'a technologie utilisé il est plus ou moin facile de trouver un hebergeur à sa convenance. L'idéal c'est au minimum un serveur virtuel ou ça va la possibilité de tout y placer.
PHP est certe intégré dans pas mal d'hebergeur mais c'est souvent lié au la distribution Linux utilisé.
Face à python et à ruby , l'avenir de php est obscure.
Les programmeurs s'orientent de plus en plus et à raison vers des langages propres , clairs avec un modéle objet abouti et une conception inspirée des design patterns comme le MVC.
Php n'a rien de tout cela , sa synthaxe est toujours aussi bordelique , le modéle objet est limité,sans parler des framework pseudo MVC.
Cependant php reste ultra accessible pour la conception de site internet tant la toile regorge de tutoriaux et d'hébergeur propices à son developpement.
Php a sans aucun doute fait l'effet d'une bombe il y a une dizaine d'année face à des mamouth comme java.
Il a rendu la conception de site internet dynamique accessible à tous et pas seulement aux pros,ce qui n'est pas une mince affaire.
Mais aujourd'hui il y dotnet,Struts et la bande à java,python et ruby on rails.
Si les deux premiers restent assez lourd à prendre en main , les deux suivants pourraient bien prendre la place de php dans les années qui viennent.
Avec le nouvel interpréteur ruby 1.9 est enfin un langage économique en ressource,ce qui laisse prévoir une ouverture massive d'hébergement gratuit ou à faible coup pour ce framework.
J'ai l'impression que php n'arrive pas à se débarasser de ses racines(à la base c'est une librairie de perl)pour devenir un langage pro et propre.
Je crois que tu t'embale un peut vite. Dire qu'il y a de plus en plus de personne qui s'oriente vers python et à ruby me parait totalement vrai.
Depuis le temps que j'entend dire que python monte, je le vois pas plus avancer. Ceci remonte à quelques années déjà. Idem pour Ruby.
Dire que PHP à une synthaxe bordelique. C'est une synthaxe générique qui à des base venant du PERL et du C. Donc dire qu'elle est bordélique c'est reprocher ses origines.
Contrairement à ce que tu dis en disant qu'il y a de plus en plus de personne faisant du Ruby, en ce moment j'entend l'inverse. Pas mal de personne ayant juré sur ce language y ont fait marche arrière.
A savoir que c'est pas forcément le plus efficace qui gagne. Pour preuve : Microsoft.
De plus, une entreprise ne prend pas le risque d'utiliser un language sur un projet. La raison principal est la maintenabilité de l'application. Il y a pas assez de personne ayant fait du Ruby et généralement ceux qui en font c'est bien souvent du bidouillage. Compararé au PHP, il y a de tout. Des amateurs comme des pro. La différence c'est que c'est facile de détecter des amateurs, des semi pro et pro. Il y a la disponibilité chez les hébergeurs, le support.
Ces pas seulement au niveau syntaxe qu'il faut juger un language. il y a beaucoup plus de paramètres qui rentre en jeux.
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