[Parser] : Javascript ou PHP ?
Résolu/Fermé
heavymac
Messages postés
11
Date d'inscription
jeudi 16 novembre 2006
Statut
Membre
Dernière intervention
29 novembre 2006
-
16 nov. 2006 à 15:22
ben - 12 nov. 2007 à 14:02
ben - 12 nov. 2007 à 14:02
A voir également:
- [Parser] : Javascript ou PHP ?
- Msxml 4.0 sp3 parser - Forum Virus
- Php ics parser ✓ - Forum PHP
- Msxml parser - Forum Logiciels
- C++ parser une string - Forum Programmation
- Parser view cisco - Forum CISCO
7 réponses
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
16 nov. 2006 à 15:40
16 nov. 2006 à 15:40
Je dirais: php.
Côté client, tout est bidouillable, je ne prendrais jamais le risque de stocker le code formatté que m'envoie le Javascript.
Certes ça fait un aller-retour, mais je pense que c'est supportable (un bouton "Prévisualiser" fera l'affaire).
Si vraiment on ne veut pas d'aller-retour trop pénible, on peut d'XmlHttpRequest devrait aider, et ça permet de garder le code qui interprète les balises côté serveur.
Côté client, tout est bidouillable, je ne prendrais jamais le risque de stocker le code formatté que m'envoie le Javascript.
Certes ça fait un aller-retour, mais je pense que c'est supportable (un bouton "Prévisualiser" fera l'affaire).
Si vraiment on ne veut pas d'aller-retour trop pénible, on peut d'XmlHttpRequest devrait aider, et ça permet de garder le code qui interprète les balises côté serveur.
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
16 nov. 2006 à 16:54
16 nov. 2006 à 16:54
je ne vois pas trop en quoi le Javascript présente tellement plus de risque ?
Accepter du code HTML venant du client pour ensuite l'afficher sur le site, c'est un risque de sécurité (cross-site scripting par exemple).
je me pose surtout la question de la rapidité d'exécution qu'il pourrait y avoir entre les deux parsers
Javascript peut parfois être lourd.
Et surtout le gros du problème, c'est que d'un navigateur à l'autre ça ne se comporte pas pareil.
ça risque d'être galère à développer.
Accepter du code HTML venant du client pour ensuite l'afficher sur le site, c'est un risque de sécurité (cross-site scripting par exemple).
je me pose surtout la question de la rapidité d'exécution qu'il pourrait y avoir entre les deux parsers
Javascript peut parfois être lourd.
Et surtout le gros du problème, c'est que d'un navigateur à l'autre ça ne se comporte pas pareil.
ça risque d'être galère à développer.
heavymac
Messages postés
11
Date d'inscription
jeudi 16 novembre 2006
Statut
Membre
Dernière intervention
29 novembre 2006
16 nov. 2006 à 17:48
16 nov. 2006 à 17:48
Accepter du code HTML venant du client pour ensuite l'afficher sur le site, c'est un risque de sécurité (cross-site scripting par exemple).
Mais il ne s'agit pas d'accepter du code HTML venant du client.
Une fois que le membre a tapé son texte, en utilisant ou non les balises de mise en forme (ex. BBcode), toutes les balises HTML sont supprimées, les balises de mises en forme sont converties (parsage) et le texte peut alors prévisualisé ou le formulaire validé.
C'est bien pour ça que je demandais quel pouvait bien être la faiblesse du Javascript par rapport au PHP puisque dans les deux langages on utilise les mêmes expressions régulières pour supprimer les balises HTML et parser le texte (même si en PHP on a des fonctions toutes faites pour ça) avant que celui-ci soit affiché ou traité.
Mais peut-être qu'un point m'a échappé ?
Javascript peut parfois être lourd.
Tu veux donc dire que le Javascript aurait tendance à bouffer plus de ressources que le PHP pour ce type de traitement ? Je pensais justement que le traitement "local" était plus rapide que le traitement "distant" ?
Et surtout le gros du problème, c'est que d'un navigateur à l'autre ça ne se comporte pas pareil.
ça risque d'être galère à développer.
Quant au problème de comptabilité, je suis bien d'accord avec toi... le Javascript est très chiant pour ça... mais je pars du principe que mon parser est compatible avec les principaux navigateurs (au moins IE et Firefox)
Mais il ne s'agit pas d'accepter du code HTML venant du client.
Une fois que le membre a tapé son texte, en utilisant ou non les balises de mise en forme (ex. BBcode), toutes les balises HTML sont supprimées, les balises de mises en forme sont converties (parsage) et le texte peut alors prévisualisé ou le formulaire validé.
C'est bien pour ça que je demandais quel pouvait bien être la faiblesse du Javascript par rapport au PHP puisque dans les deux langages on utilise les mêmes expressions régulières pour supprimer les balises HTML et parser le texte (même si en PHP on a des fonctions toutes faites pour ça) avant que celui-ci soit affiché ou traité.
Mais peut-être qu'un point m'a échappé ?
Javascript peut parfois être lourd.
Tu veux donc dire que le Javascript aurait tendance à bouffer plus de ressources que le PHP pour ce type de traitement ? Je pensais justement que le traitement "local" était plus rapide que le traitement "distant" ?
Et surtout le gros du problème, c'est que d'un navigateur à l'autre ça ne se comporte pas pareil.
ça risque d'être galère à développer.
Quant au problème de comptabilité, je suis bien d'accord avec toi... le Javascript est très chiant pour ça... mais je pars du principe que mon parser est compatible avec les principaux navigateurs (au moins IE et Firefox)
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
16 nov. 2006 à 21:43
16 nov. 2006 à 21:43
les balises de mises en forme sont converties
converties en quoi ?
en d'autres balises spéciales ?
en html ?
Qu'est-ce que tu stock côté serveur ?
Tu veux donc dire que le Javascript aurait tendance à bouffer plus de ressources que le PHP pour ce type de traitement ?
Disons que ça peut être lourd. ça dépend de ce que tu fais.
(Exemple: le bout de javascript tout à la fin de cette page est tout simple, mais ça bouffe du CPU. C'est acceptable sur les machines puissantes, mais sur un Pentium 200, c'est lourd).
converties en quoi ?
en d'autres balises spéciales ?
en html ?
Qu'est-ce que tu stock côté serveur ?
Tu veux donc dire que le Javascript aurait tendance à bouffer plus de ressources que le PHP pour ce type de traitement ?
Disons que ça peut être lourd. ça dépend de ce que tu fais.
(Exemple: le bout de javascript tout à la fin de cette page est tout simple, mais ça bouffe du CPU. C'est acceptable sur les machines puissantes, mais sur un Pentium 200, c'est lourd).
heavymac
Messages postés
11
Date d'inscription
jeudi 16 novembre 2006
Statut
Membre
Dernière intervention
29 novembre 2006
16 nov. 2006 à 22:42
16 nov. 2006 à 22:42
les balises de mises en forme sont converties
converties en quoi ?
en d'autres balises spéciales ?
en html ?
Qu'est-ce que tu stock côté serveur ?
Les balises de mise en forme correspondent aux balises BBcode par exemple. Elles sont donc converties en balises HTML (après que les balises HTML aient été toutes supprimées bien sûr)
En mode "Prévisualiser", le texte ainsi traité est simplement affiché.
En mode "Valider" (i.e. validation du formulaire), le texte envoyé côté serveur est le texte contenant les balises BBcode (prend moins de place dans la base)... même si ça serait peut-être mieux d'envoyer le texte avec les balises HTML puisque je l'ai déjà côté client et de l'insérer tel quel dans la base.
Se pose donc la question de savoir quelle est la solution optimale concernant toutes ces questions de parser (Javascript ou PHP) et de stockage (avec balises modifiées ou balises HTML)...
converties en quoi ?
en d'autres balises spéciales ?
en html ?
Qu'est-ce que tu stock côté serveur ?
Les balises de mise en forme correspondent aux balises BBcode par exemple. Elles sont donc converties en balises HTML (après que les balises HTML aient été toutes supprimées bien sûr)
En mode "Prévisualiser", le texte ainsi traité est simplement affiché.
En mode "Valider" (i.e. validation du formulaire), le texte envoyé côté serveur est le texte contenant les balises BBcode (prend moins de place dans la base)... même si ça serait peut-être mieux d'envoyer le texte avec les balises HTML puisque je l'ai déjà côté client et de l'insérer tel quel dans la base.
Se pose donc la question de savoir quelle est la solution optimale concernant toutes ces questions de parser (Javascript ou PHP) et de stockage (avec balises modifiées ou balises HTML)...
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
16 nov. 2006 à 23:18
16 nov. 2006 à 23:18
En mode "Valider" (i.e. validation du formulaire), le texte envoyé côté serveur est le texte contenant les balises BBcode
ah ok.
alors c'est bon question sécurité.
Quant à la solution optimale, difficile à dire.
ah ok.
alors c'est bon question sécurité.
Quant à la solution optimale, difficile à dire.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
oberion
Messages postés
1253
Date d'inscription
mardi 26 septembre 2006
Statut
Membre
Dernière intervention
29 septembre 2007
248
17 nov. 2006 à 10:19
17 nov. 2006 à 10:19
Bonjour,
Il existe une troisieme solution. Et celle ci est peut etre meme la plus propre. Fais une feuille de style XSLT, en une demi journée, c'est baclé.
Avantage, les memes que le js, à savoir, c'est coté client que ca s'execute, le serveur n'est pas chargé. C'est moins cramouche que le Js et plus rapide à développer que le PHP.
Perso, c'est comme ca que je ferais.
Il existe une troisieme solution. Et celle ci est peut etre meme la plus propre. Fais une feuille de style XSLT, en une demi journée, c'est baclé.
Avantage, les memes que le js, à savoir, c'est coté client que ca s'execute, le serveur n'est pas chargé. C'est moins cramouche que le Js et plus rapide à développer que le PHP.
Perso, c'est comme ca que je ferais.
heavymac
Messages postés
11
Date d'inscription
jeudi 16 novembre 2006
Statut
Membre
Dernière intervention
29 novembre 2006
24 nov. 2006 à 14:23
24 nov. 2006 à 14:23
La solution d'une feuille de style XSLT me paraît être la meilleure solution pour concilier à la fois un parser et un traitement côté client.
En effet, XSLT permet d'appliquer aux données d'un fichier XML des "motifs" (sorte d'expressions régulières) qui font office de parser.
En effet, XSLT permet d'appliquer aux données d'un fichier XML des "motifs" (sorte d'expressions régulières) qui font office de parser.
mauvaise comprehension de la chose
la feuille xsl n est pas un parser mais un ensemble de regles de transformations a appliquer a un fichier xml
ensuite c est le parser du navigateur qui est utilise (et il varie suivant les navigateurs bien sur... mais pas de panique seuls les fonctions avancees et les 'points de detail' different reellement)
je suppose que les motifs dont tu parles sont les templates auquel cas la syntaxe des patterns est tout de meme tres eloignee de celle des RegExps
mais tu as la bonne solution en main manifestement
la feuille xsl n est pas un parser mais un ensemble de regles de transformations a appliquer a un fichier xml
ensuite c est le parser du navigateur qui est utilise (et il varie suivant les navigateurs bien sur... mais pas de panique seuls les fonctions avancees et les 'points de detail' different reellement)
je suppose que les motifs dont tu parles sont les templates auquel cas la syntaxe des patterns est tout de meme tres eloignee de celle des RegExps
mais tu as la bonne solution en main manifestement
16 nov. 2006 à 16:02
Je suis d'accord avec toi pour le côté "tout est bidouillable côté client" mais si on part du principe que le parser, qu'il soit en Javascript ou en PHP, se sert d'expressions régulières pour convertir les balises du texte en balises HTML, je ne vois pas trop en quoi le Javascript présente tellement plus de risque ?
D'autre part, l'avantage du parser Javascript est qu'il permet une Prévisualisation instantannée... et qu'il reste toujours possible, même si cela fait double emploi, d'envoyer le texte brut et de le retraiter côté serveur via un parser PHP.
En fait, je me demande dans quelle mesure deux parsers ne seraient pas utiles mais je trouve que cela fait double emploi et je me pose surtout la question de la rapidité d'exécution qu'il pourrait y avoir entre les deux parsers.