Quick links: Content - sections - sub sections
EN FR
Quick Search Advanced search
 
Page

  [Opened] À propos de l'utilisation de jforms dans les réponses Ajax (prise en charge de addJSLink)

Citation de la documentation :

Il y a un souci connu quand on utilise un formulaire jforms dans un template pour une réponse autre que html pour faire une réponse ajax.

En effet, pour fonctionner correctement, un formulaire jforms a besoin de la présence du fichier jforms.js dans la page qui appelle la requête ajax. Ce fichier est inclus automatiquement par le plugin form, en appelant la méthode addJsLink de la réponse.

Comme les fragments HTML renvoyés par les reponses ajax n'ont pas d'en-tête HTML <head>, le script n'est pas inclus dans la page html final, ce qui causera des erreurs javascript. Pour le moment, il n'y a pas d'autre solution que d'inclure ce script jforms.js “à la main” lors de la génération de la page hôte (celle qui fait donc la requête ajax).

J'ai une suggestion par rapport à un éventuel support par les réponses json et htmlfragment de addJSLink : Il s'agit d'une méthode pour démarrer un script js dynamiquement. cf. http://unixpapa.com/js/dyna.html. J'ai ressassé un vieux ticket à cet occasion : http://developer.jelix.org/ticket/792. L'idée est elle convenable ?

  [Opened] À propos de l'utilisation de jforms dans les réponses Ajax (prise en charge de addJSLink)

bonjour,

non, parce que de toute manière, jelix n'a aucun moyen de savoir si le script n'est pas déjà inclus dans la page ou pas. ce qu'il faudrait savoir avant de générer ou pas du js dans le htmlfragment.

  [Opened] À propos de l'utilisation de jforms dans les réponses Ajax (prise en charge de addJSLink)

Avec un js qui vérifie la présence des objets dans le dom et qui ensuite chargerai avec $.getScript les script Js nécessaire, ce ne serait pas possible ?

  [Opened] À propos de l'utilisation de jforms dans les réponses Ajax (prise en charge de addJSLink)

peut être. ça me parait un peu bout de scotch tout ça... je ne sais pas.. jforms n'a pas été pensé pour être généré par de l'ajax (ouai, pas cool, mais c'était déjà assez compliqué comme ça au début de sa conception). il faudrait avoir une réflexion un peu plus approfondi sur jforms en général pour apporter des réponses plus globales.. mais là, tout de suite, pas le temps d'y réfléchir...

PS: je ne dis pas que ta solution n'est pas bonne, c'est simplement que pour l'instant, je n'ai pas vraiment d'opinion

  [Opened] À propos de l'utilisation de jforms dans les réponses Ajax (prise en charge de addJSLink)

Dommage!

Je ne penses pas que cette solution soit sale. Par ailleurs, je pense que partir du principe que cette solution concerne exclusivement jform serait une erreur. En effet, la prise en charge de addJSLink par les réponses htmlFragments et jSons offrirait une souplesse importante pour faire de l'ajax en général. Alors qu'une étude approfondie de jform pour régler ce problème pourrait inutilement compliquer jform, et être source d'inutiles pertes de performance côté serveur, voire de bugs des deux côtés.

Je respecte le fait qu'il ne soit pas au gout du jour de régler ce problème, gérer une timeline doit être difficile. Je me permets malgrès tout de transmettre mes quelques petites réflexions. Libre à tous de les prendre en considération à un moment jugé propice.

Je ne vois que deux solutions :

  • retenir dans une variable session les données méta de la dernière réponse html nécessaires pour ne pas charger un JS en double (ça, je penses que c'est sale!)
  • Une simple petite analyse du DOM et un chargement dynamique du/des scripts nécessaires. (c'est vraiment pas la mer à boire!)

Le prix pourrait vraiment ne pas être cher payé pour bénéficier d'une souplesse d'intégration de l'ajax très appréciable.

PS : Laurent, ne te sent pas obligé d'y réfléchir maintenant si ça te saoul. Si le post tombe aux oubliettes et que la question ressurgi de nouveau plus tard, et elle ressurgira, il sera toujours possible de faire un liens vers ce post... On est pas à l'usine!

Ciao wink

  [Opened] À propos de l'utilisation de jforms dans les réponses Ajax (prise en charge de addJSLink)

En effet, la prise en charge de addJSLink par les réponses htmlFragments et jSons offrirait une souplesse importante pour faire de l'ajax en général

pour htmlfragment, oui. Pour json, je ne vois pas par contre, ce n'est pas du js qui est executé...

retenir dans une variable session les données méta de la dernière réponse html nécessaires pour ne pas charger un JS en double (ça, je penses que c'est sale!)

sale est surtout super trop complexe : le user peut très bien ouvrir entre temps des pages dans d'autres onglets...

Une simple petite analyse du DOM et un chargement dynamique du/des scripts nécessaires. (c'est vraiment pas la mer à boire!)

il faut résoudre les chemins des scripts, relativement à l'url de la page, c'est embetant (genre, detecter que /jelix/truc.js == ../../../jelix/truc.js si la page = /aaa/bbb/ccc/ ), à moins que jquery ou autre le font

Laurent, ne te sent pas obligé d'y réfléchir maintenant si ça te saoul.

c'est plus un manque de temps que de "saoulage" wink

  [Opened] Re: À propos de l'utilisation de jforms dans les réponses Ajax (prise en charge de addJSLink)

Il y a plusieurs sujets là:

  • jForm utilise beaucoup de javascript et ne fonctionne pas "bien" sans
  • intégrer un js dans un HTMLfragment n'est pas prévu

Une grosse partie du javascript intégré par jForm permet d'atteindre une équivalence avec form de html5. Je pense qu'il ne resterait plus grand chose en terme de js à envoyer au navigateur si on crée un builder HTML5 pour jForm.

Après addJSLink pour les htmlFragments... c'est vraiment utile ? Après tout,

  • le JS est dans le cache du navigateur (et même sans ça il est compacté) donc le temps de téléchargement est négligeable
  • le javascript s'applique par selecteur CSS3, donc pas d'effets indésirables
  • les interpréteurs JS sont super rapides

Pour moi, il vaut mieux balancer tout le JS dans le head quoi qu'il arrive et laisser le navigateur/proxy/cache/interpréteur JS se débrouiller avec.

  [Opened] À propos de l'utilisation de jforms dans les réponses Ajax (prise en charge de addJSLink)

Une grosse partie du javascript intégré par jForm permet d'atteindre une équivalence avec form de html5. Je pense qu'il ne resterait plus grand chose en terme de js à envoyer au navigateur si on crée un builder HTML5 pour jForm.

Encore faut il que TOUT les navigateurs supportent HTML5, ou le même ensemble de balise HTML5. Et ce n'est pas le cas, donc il faut quand même avoir tout ce JS pour les "vieux" navigateurs.

  [Opened] À propos de l'utilisation de jforms dans les réponses Ajax (prise en charge de addJSLink)

Après addJSLink pour les htmlFragments... c'est vraiment utile ?

Et bien si on se place du point de vue intégrateur, ça peut franchement l'être. Si on décide de faire cohabiter dans un même site plusieurs applications javascript, et que l'on souhaite, par exemple, la possibilité de charger les pages du site en ajax, là ça devient très pratique... (il me semble. En tout cas, je me trouve dans cette difficulté de conception là)

  [Opened] À propos de l'utilisation de jforms dans les réponses Ajax (prise en charge de addJSLink)

propose alors un patch smile

 
Page
  1. À propos de l'utilisation de jforms dans les réponses Ajax (prise en charge de addJSLink)