Plein .. la connectivité c'est LE point fort de PHP. PHP est surtout fait pour gérer des frontal Web, et se connecter avec une application ou un autre composant qui gèrera le métier.
Ca donne déjà un bon panel des possibilités (j'ai ouie dire aussi d'un connecteur ruby mais il n'a pas l'air de se trouver officialisé sur PHP, PEAR ou PECL).
Dans l'optique inverse on peut intégrer PHP comme langage de script d'une plus grosse application (à la manière d'ActivePerl et autres) : http://pecl.php.net/package/PHPScript(...)
L'extension Java n'a pas été portée vers PHP5 mais Sun a décidé de faire toutes ses implémentations de référence pour son futur JSR avec PHP. Sun s'est donc engagé avec Zend pour réaliser la connectivité complète PHP/Java (dans les deux sens). C'est à priori un gage de sérieux et de pérénité pour les interractions avec Java (le temps qu'ils fassent l'implémentation PHP5).
Coté plus applicatif on a aussi des connecteurs vers pas mal de trucs. Au dernier forum PHP on avait une entreprise qui exposait ce qu'elle a fait sur son intranet : un frontal PHP qui se connecte à leur ERP SAP pour le piloter et fournir des interfaces Web pour les trucs utilisés.
L'idée est là : pas de refaire l'application Java ou de refaire un ERP, mais de faire rapidement un frontal très simple qui utilise des connecteurs pour chercher la logique métier. PHP s'occupe alors de la partie Web (et uniquement de la partie Web) en évitant de monter tout un J2EE et des concepts complexes là où ce n'est pas nécessaire.
> mais qui doit-on accabler?
Pas le langage certes, mais quand on me dit que ça ne gère pas X, Y, Z ... la question est souvent "oui, mais vous en avez vraiment besoin ? si vous repartez sur quelques petites lignes simples au lieu de faire une grosse architecture monstre, vous n'en auriez peut être pas besoin.
[^] # Re: Le php
Posté par Éric (site web personnel) . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 5.
Plein .. la connectivité c'est LE point fort de PHP. PHP est surtout fait pour gérer des frontal Web, et se connecter avec une application ou un autre composant qui gèrera le métier.
- utilisations d'objets COM et composants .NET sous Windows : http://www.php.net/manual/en/ref.com.php(...)
- utilisation d'objets .NET avec Mono : http://pecl.php.net/package/mono(...)
- utilisations d'objets Java (PHP4 uniquement) : http://www.php.net/manual/en/ref.java.php(...)
- utilisation d'une librairie partagée (en C ?) arbitraire : http://pecl.php.net/package/ffi(...)
- utilisation de code et d'objets Perl : http://pecl.php.net/package/perl(...)
- utilisation de code et d'objets Python : http://pecl.php.net/package/python(...)
Plus génériques :
- par XML-RPC : http://www.php.net/manual/en/ref.xmlrpc.php(...)
- par SOAP : http://fr.php.net/soap(...)
Ca donne déjà un bon panel des possibilités (j'ai ouie dire aussi d'un connecteur ruby mais il n'a pas l'air de se trouver officialisé sur PHP, PEAR ou PECL).
Dans l'optique inverse on peut intégrer PHP comme langage de script d'une plus grosse application (à la manière d'ActivePerl et autres) : http://pecl.php.net/package/PHPScript(...)
L'extension Java n'a pas été portée vers PHP5 mais Sun a décidé de faire toutes ses implémentations de référence pour son futur JSR avec PHP. Sun s'est donc engagé avec Zend pour réaliser la connectivité complète PHP/Java (dans les deux sens). C'est à priori un gage de sérieux et de pérénité pour les interractions avec Java (le temps qu'ils fassent l'implémentation PHP5).
Coté plus applicatif on a aussi des connecteurs vers pas mal de trucs. Au dernier forum PHP on avait une entreprise qui exposait ce qu'elle a fait sur son intranet : un frontal PHP qui se connecte à leur ERP SAP pour le piloter et fournir des interfaces Web pour les trucs utilisés.
L'idée est là : pas de refaire l'application Java ou de refaire un ERP, mais de faire rapidement un frontal très simple qui utilise des connecteurs pour chercher la logique métier. PHP s'occupe alors de la partie Web (et uniquement de la partie Web) en évitant de monter tout un J2EE et des concepts complexes là où ce n'est pas nécessaire.
> mais qui doit-on accabler?
Pas le langage certes, mais quand on me dit que ça ne gère pas X, Y, Z ... la question est souvent "oui, mais vous en avez vraiment besoin ? si vous repartez sur quelques petites lignes simples au lieu de faire une grosse architecture monstre, vous n'en auriez peut être pas besoin.