Page 1 sur 2
PHP sans serveur
Posté : 29 oct. 2006, 13:15
par freex
Bonjour,
J'attend le jour où je pourrai faire fonctionner mes scripts PHP sans serveur, via un fichier exécutable ...un peu comme on fait avec perl ou java où il suffit d'appliquer une fonction sur le code pour l'envoyer dans un fichier ".exe"
Je pense que l'idée est intéressante puisqu'elle permet au programmeur n'ayant pas l'habitude de (ou ne voulant pas) jouer avec les librairies GUI de pouvoir créer une interface graphique valide (puisque code HTML) sans devoir se casser la tête et/ou passer par des licences payantes.
le 127.0.0.1 serait remplacé par le directory où se trouve le fichier et chaque fichier serait intérprété par une librairie (.dll par exemple) fonctionnant sans Apache.
Est-ce si compliqué de développer cela?
Posté : 29 oct. 2006, 13:27
par Cyrano
fais une petite recherche sur "PHP GTK"
Posté : 29 oct. 2006, 14:11
par freex
C'est bien là le problème, il faut manipuler GTK.
Pourquoi ne pas se limiter à l'utilisation du html et ouvrir les .php via le navigateur web? ça éviterait ce genre de chose :
Voici ce que j'ai trouvé sur le web simplement pour faire apparaître une petite fenêtre qui dit "Salut tt le monde" :
Code : Tout sélectionner
<?php
if ( !class_exists("gtk")) {
if (strtoupper(substr(PHP_OS, 0, 3)) == "WIN")
dl("php_gtk.dll");
else
dl("php_gtk.so");
}
function destroy() {
Gtk::main_quit();
}
$objWindow = &new GtkWindow();
$objVBox = &new GtkVBox(false, 10);
$objLabel = &new GtkLabel("Salut tt le monde");
$objButton = &new GtkButton("Fermer");
$objWindow->set_title("Salut tt le monde");
$objWindow->set_border_width(5);
$objWindow->connect("destroy", "destroy");
$objButton->connect("clicked", "destroy");
$objVBox->pack_start($objLabel);
$objVBox->pack_start($objButton);
$objWindow->add($objVBox);
$objWindow->show_all();
gtk::main();
?>
En se passant du GTK au bénéfice du HTML via navigateur, il suffisait d'écrire ceci :
...ce qui est plus simple non?
Peut-être que l'interface GTK offre des fonctionnalités plus élaborées, je ne sais pas mais pour moi (et pour bcp d'autre probablement) le but est de pouvoir utiliser les scripts tant sur le web qu'en stanalone avec un MINIMUM de modification (voir pas du tout).
Y a-t-il des développements futur allant dans ce sens?
Posté : 29 oct. 2006, 14:16
par rami
Et comment rendre le contenu graphique HTML dans un client lourd?
Si tu passes par le navigateur, tu dois forcément passer par HTTP.
Il faudrait pour cela utiliser le moteur de rendu du navigateur sans passer par le navigateur, et donc développer une interface entre PHP et le moteur de rendu, chose qui n'existe pas à ma connaissance...
Posté : 29 oct. 2006, 14:30
par freex
Et comment rendre le contenu graphique HTML dans un client lourd?
Si tu passes par le navigateur, tu dois forcément passer par HTTP.
Il faudrait pour cela utiliser le moteur de rendu du navigateur sans passer par le navigateur, et donc développer une interface entre PHP et le moteur de rendu, chose qui n'existe pas à ma connaissance...
Quel est le problème avec http? il suffit de pointer vers le fichier .php via le navigateur non? ce n'est pas le navigateur qui intérprete le .php, ce serait une librairie dédiée.
...ou alors j'ai pas compris ta question...
Posté : 29 oct. 2006, 15:21
par Cyrano
Qui dit protocole http dit forcément serveur http ce me semble
Posté : 29 oct. 2006, 15:39
par rami
Si tu pointes (en local) directement vers ton fichier php, celui-ci sera affiché tel quel!
Le fait d'utiliser un serveur web permet justement d'interpréter le fichier PHP avant d'envoyer une réponse au navigateur!!!
Posté : 29 oct. 2006, 18:06
par freex
Oui, je me suis trompé, il ne faudrait pas de http en effet, exemple :
j'ai un fichier essai.php sur la racine du disque C.
Pour le lancer, soit je clique dessus, soit je tape "file:///C:/essai.php" dans la barre d'adresse de mon navigateur.
Il suffit de faire comprendre au navigateur que "file:///" + chemin + mon_fichier.php doit (si absence de serveur sur 127.0.0.1) être envoyé à un interpréteur de PHP (différent de PHP pour serveur donc) qui, à la différence de PHP-GTK, utiliserai le navigateur en question comme GUI en lieu et place du GTK.
=> pas besoin de http ni de serveur web ni de librairie GUI
Les avantages d'une telle solution me semblent tellement évidents que j'ai du mal à croire qu'aucun développeur n'ai rien programmé en ce sens...
suis-je fou de penser que ce soit possible?
Posté : 29 oct. 2006, 19:21
par rami
Il faudrait pour cela une interface standard de communication entre le moteur de rendu des navigateurs et PHP, ce qui exclut IE , vu que son code est propriétaire...
Posté : 29 oct. 2006, 20:09
par Invité
Il faudrait pour cela une interface standard de communication entre le moteur de rendu des navigateurs et PHP, ce qui exclut IE , vu que son code est propriétaire...
Pour quoi faire??
Que je sache, l'interpréteur PHP (pour serveur) n'a pas de lien direct et/ou privilégié avec les moteur graphique des navigateurs.
J'ai l'impression de ne pas me faire comprendre...
ma proposition était :
le
navigateur ouvre un fichier
PHP, il le passe à un
interpréteur (fonctionnant sans serveur, sans apache et sans GUI) et le
résultat ne serait autre que du code
HTML renvoyé au navigateur qui se chargera de l'afficher comme une page HTML, comme il l'a toujours fait avec les sites web.
Ou vois-tu la nécessité d'utiliser une interface standard avec les moteur de rendu des navigateur?
Posté : 29 oct. 2006, 20:16
par freex
...J'avais oublié de me connecter...
Pour résumer très simplement, ma proposition est de remplacer le couple Apache/PHP par un "fichier exécutable"/PHP
Posté : 30 oct. 2006, 12:48
par zigz4g
Hummm le principe de base serait bien sympathique.
Mais je vois mal FF ou IE mettre un plugin PHP dans leur application.
Surtout qu'il faut compiler PHP avec toutes les options possibles pour que tu puissent faire tourner tous les scripts possibles.
En gros faudrait qu'une extension prenne la librairie de PHP pour parser et analyser le contenu de fichier php.
Faut voir aussi comment detecter que c'est bien du php. Peut etre avec les types mimes ou bien en fonction de l'extension.
EDIT: Je rajouterais comment faire les connexions vers les bases de donnees ???
Posté : 30 oct. 2006, 13:29
par mere-teresa
Les avantages d'une telle solution me semblent tellement évidents que j'ai du mal à croire qu'aucun développeur n'ai rien programmé en ce sens...
suis-je fou de penser que ce soit possible?
Ben heu, quelque chose a été programmé en ce sens, et on te l'a signalé, il s'agit de PHP-GTK.
Ce que PHP peut faire
Le compileur bytecode de PHP
Par ailleurs, si tu souhaites éviter le protocole HTTP, je ne crois pas que le protocole file:/// pourra suffire.
Hophop sur Wikipédia pour tous les protocoles
Par ailleurs, rassure moi, tu souhaites avoir une appli pour ton Windows only...et tu as déjà regardé sur le forum les moyens de convertir un site en PHP en une application .exe
Posté : 30 oct. 2006, 17:47
par mcorgnet
ça ressemble étrangement à du troll ... du genre : j'vous titille à fond histoire de vous dire que si j'étais le maître du monde, ça serait mieux.
Posté : 30 oct. 2006, 20:10
par freex
...je vois mal FF ou IE mettre un plugin PHP dans leur application.
Surtout qu'il faut compiler PHP avec toutes les options possibles pour que tu puissent faire tourner tous les scripts possibles...
...En gros faudrait qu'une extension prenne la librairie de PHP pour parser et analyser le contenu de fichier php....
....EDIT: Je rajouterais comment faire les connexions vers les bases de donnees ???
A part le plugin pour navigateur, ce que tu décris se fait bien pour PERL. Je ne vois donc pas en quoi est-ce une mission impossible
...Oui bon, la connexion au DB via le navigateur devrait être codée ds le plugin je suppose.
Soit, je vois que cette solution n'existe pas, dommage... tt le monde n'est pas informaticien. Moi je suis webdesigner et j'utilise de temps à autre du PHP, si je pouvait faire quelque outils utiles sans avoir à me casser la tête avec du GUI type GTK, ce serait Bysance.