PHP sans serveur

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : PHP sans serveur

par freex » 30 oct. 2006, 20:22

ç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.
Hmmmm très intéressant ton point de vue mon gars, surtout si tu signes tes messages avec "l'avis du citoyen".
Là, je ris :D :D :D

par freex » 30 oct. 2006, 20:17


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



Ouuuiiiiiiiiiiiiii, c'est ça :D ...mais j'ai pas trouvé une solution SIMPLE :(

... Entendons-nous bien, je dis simple pour l'utilisateur final, pas pour les éventuels informaticiens chargé de développer ce PHP "stand-alone"

par freex » 30 oct. 2006, 20:10

...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.

par mcorgnet » 30 oct. 2006, 17:47

ç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.

par mere-teresa » 30 oct. 2006, 13:29

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

par zigz4g » 30 oct. 2006, 12:48

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 ???

par freex » 29 oct. 2006, 20:16

...J'avais oublié de me connecter... :D

Pour résumer très simplement, ma proposition est de remplacer le couple Apache/PHP par un "fichier exécutable"/PHP

par Invité » 29 oct. 2006, 20:09

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?

par rami » 29 oct. 2006, 19:21

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...

par freex » 29 oct. 2006, 18:06

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?

par rami » 29 oct. 2006, 15:39

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!!!

par Cyrano » 29 oct. 2006, 15:21

Qui dit protocole http dit forcément serveur http ce me semble :-k

par freex » 29 oct. 2006, 14:30

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...

par rami » 29 oct. 2006, 14:16

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...

par freex » 29 oct. 2006, 14:11

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 :

Code : Tout sélectionner

alert ("Salut tt le monde");
...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?