Re: Question pratique
On Wednesday 28 August 2002 17:45, Jean-Bruno Luginbühl wrote: > Juste une parenthèse, avec leshop on peut, maintenant et depuis une > demande de ma part, accéder avec Netscape 4.75 sous Linux (ce n'était > pas reconnu avant). Ils m'ont promis de travailler pour un > fonctionnement correct sous Mozilla 1.0. (cf un post de ma part > précédent avec une de leur réponse). Ça fait trois mois qu'ils me promettent la même chose ! Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
On Wednesday 28 August 2002 17:42, Jean-Bruno Luginbühl wrote: > D'accord, recharger toute la page c'est ennuyeux, mais ne peut-on pas > (et je ne suis pas un expert - loin s'en faut - en applications > web-java-php) avec un script java n'afficher que les modifications du > tableau dans la page. On peut, mais ça devient assez scabreux... de plus j'utilise un "frame" caché pour le passage et le retour des requêtes. Intellectuellement intéressant, mais pas vraiment recommandable, car bricole. Donc, PHP-MySQL est bien dans ce cas (et dans bien d'autre). Danie -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
Le mer 28/08/2002 à 17:04, Daniel Cordey a écrit : > > Encore un plug-in (contrairement à JS). J'ai aussi un paquet de site avec des > applets que je n'arrive jamais à accéder (www.leshop.ch) et des sites qui > abusent avec le JS (www.nasdaq.com). Toutes les horreurs et les goûts sont > dans la nature :-) Juste une parenthèse, avec leshop on peut, maintenant et depuis une demande de ma part, accéder avec Netscape 4.75 sous Linux (ce n'était pas reconnu avant). Ils m'ont promis de travailler pour un fonctionnement correct sous Mozilla 1.0. (cf un post de ma part précédent avec une de leur réponse). Jean-Bruno -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
Le mer 28/08/2002 à 16:59, Daniel Cordey a écrit : > On Wednesday 28 August 2002 16:17, Jean-Bruno Luginbühl wrote: > > mais on peut très bien imaginer dans > > mon cas (surtout dans mon cas, puisque je voudrais être > > multi-plateforme) avoir une application intranet sans pour autant faire > > un submit, mais avoir également la liste qui change, non? > > Oui, mais dans un concept browser-webserveur, l'intercation, comme tu les dis, > est moins évidente à réaliser. En effet, il n'est pas pensable d'effcetuer > une recherche pour chaque letter frapée. Par contre, il est tout à fait > envisageable d'effectuer un genre de recherche par étape : tu tapes une ou > deux lettres, lance la requête qui te présente un choix plus restreint, etc. > D'accord, recharger toute la page c'est ennuyeux, mais ne peut-on pas (et je ne suis pas un expert - loin s'en faut - en applications web-java-php) avec un script java n'afficher que les modifications du tableau dans la page. Actuellement cela fonctionne (enfin!) avec cette application et MySQL, et de la même manière qu'avec l'application Windev (nb maintenant on va passer à Postgresql, mais les routines sont les même et cela ne devrait donc pas poser de problèmes...). On pourrait ainsi faire de même dans une page d'un browser (en Java avec du php sur le serveur web pour des requêtes sur la base MySQL a moins qu'on puisse l'attaquer directement en java), car pour nous c'est vraiment un gain de temps apréciable! Faire une requête me parrait moins bon. Jean-Bruno > Daniel > > > > -- > http://www-internal.alphanet.ch/linux-leman/ avant de poser > une question. Ouais, pour se désabonner aussi. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
On Wednesday 28 August 2002 17:10, Sebastien Cevey wrote: > Mais (1) dans le cadre d'un intranet, on sait quel sont les browsers > utilisés donc on peut assurer le support java, (2) on est certain du > comportement dès lors que le browser intégre la JVM. Oui, mais l'expérience montre que l'on commence toujours par un réseau et des sytêmes homogènes et que l'on fini toujours par un ensemble hetérogène au bout d'un temps T :-) Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
On Wednesday 28 August 2002 17:08, Sebastien Cevey wrote: > Par exemple un site qui propose une completion javascript pour ses > clients : il ne faudrait pas que ce soit un probleme dans le cas ou le > client utilise un galeon pas tout à fait à jour. Mais pourquoi pas > proposer une page server-side "au cas où" la page js ne fonctionne > pas. C'est juste, mais en pratique tu n'as jamais le temps de le faire... > Dans cette discussion, javascript est utilisé pour faciliter ou > accélérer l'utilisation. Mais il faut veiller, surtout dans un cadre > public, à ce que ca ne pose jamais de probleme d'acces. Tu sembles > dire que du bon JS c'est 100% compatible avec tous les browsers, mais > j'ai encore qq doutes ;-) Non, je veux dire du JS simple... je ne sais pas ce qu'est du bon JS :-) Pour moi, du JS simple se contente de manipuler ses variables et les forms[] d'un document. Punkt ! Sorti de là, tu cherches les problèmes... et tu finis par les trouver :-) Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
On Wed, Aug 28, 2002 at 05:04:46PM +0200, Daniel Cordey wrote: > > Sinon, ya aussi la possibilité de faire une application ou applet > > java, donc le comportement est au moins standardisé par java et non > > pas propre à chaque browsers (ok un applet pour un input ...). > > Encore un plug-in (contrairement à JS). J'ai aussi un paquet de site avec des > applets que je n'arrive jamais à accéder (www.leshop.ch) et des sites qui > abusent avec le JS (www.nasdaq.com). Toutes les horreurs et les goûts sont > dans la nature :-) Tout à fait j'aime pas non plus :) Mais (1) dans le cadre d'un intranet, on sait quel sont les browsers utilisés donc on peut assurer le support java, (2) on est certain du comportement dès lors que le browser intégre la JVM. Mais bon, c'est une alternative, pas forcément la meilleure, je le concède ! -- Sebastien Cevey <[EMAIL PROTECTED]> Cine7 - www.cine7.net Milcis - www.milcis.net ICQ: 48895760 -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
On Wed, Aug 28, 2002 at 04:54:26PM +0200, Daniel Cordey wrote: > > En PHP, si ca marche avec un browser, ca marche aussi avec les autres ... > > Non, il faudrait dire : en HTML pure et dure. Oui c'est juste, pardon :) > > Enfin je pense que ca peut etre pratique de le faire en JS, mais alors > > au moins laisser une porte de secours alternative JS-free pour ceux > > qui ont des problemes ... > > De quels problèmes veux-tu parler ? Par exemple un site qui propose une completion javascript pour ses clients : il ne faudrait pas que ce soit un probleme dans le cas ou le client utilise un galeon pas tout à fait à jour. Mais pourquoi pas proposer une page server-side "au cas où" la page js ne fonctionne pas. Dans cette discussion, javascript est utilisé pour faciliter ou accélérer l'utilisation. Mais il faut veiller, surtout dans un cadre public, à ce que ca ne pose jamais de probleme d'acces. Tu sembles dire que du bon JS c'est 100% compatible avec tous les browsers, mais j'ai encore qq doutes ;-) -- Sebastien Cevey <[EMAIL PROTECTED]> Cine7 - www.cine7.net Milcis - www.milcis.net ICQ: 48895760 -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
On Wednesday 28 August 2002 16:36, Sebastien Cevey wrote: > Sinon, ya aussi la possibilité de faire une application ou applet > java, donc le comportement est au moins standardisé par java et non > pas propre à chaque browsers (ok un applet pour un input ...). Encore un plug-in (contrairement à JS). J'ai aussi un paquet de site avec des applets que je n'arrive jamais à accéder (www.leshop.ch) et des sites qui abusent avec le JS (www.nasdaq.com). Toutes les horreurs et les goûts sont dans la nature :-) Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
On Wednesday 28 August 2002 16:17, Jean-Bruno Luginbühl wrote: > mais on peut très bien imaginer dans > mon cas (surtout dans mon cas, puisque je voudrais être > multi-plateforme) avoir une application intranet sans pour autant faire > un submit, mais avoir également la liste qui change, non? Oui, mais dans un concept browser-webserveur, l'intercation, comme tu les dis, est moins évidente à réaliser. En effet, il n'est pas pensable d'effcetuer une recherche pour chaque letter frapée. Par contre, il est tout à fait envisageable d'effectuer un genre de recherche par étape : tu tapes une ou deux lettres, lance la requête qui te présente un choix plus restreint, etc. Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
On Wednesday 28 August 2002 16:08, Sebastien Cevey wrote: > En PHP, si ca marche avec un browser, ca marche aussi avec les autres ... Non, il faudrait dire : en HTML pure et dure. PHP peut envoyer ce qu'il veut au browser, y compris du JS, du HTML ou du XML. C'est donc le choix de ce qui est envoyé au browser qui est important, pas ce qui tourne sur le serveur. > Et meme si on admet que la faute est au browser, dire "bah utilise un > browser moins pourri", ca me semble un peu gênant :) Disons que c'est très dépendant de l'usage du serveur. Parmis le milion de requêtes (pas hits !) sur notre serveur client (pas le public) effectué chaque années, je n'ai rien trouvé d'autre que IE, N, Mozilla/Gecko, Konqueror, Opera. C'est donc ceux-ci que j'essaie de satisfaire en essayant d'y consacrer un minimum de ressources. Il faut bien avouer que l'emploi de certains browsers relève d'un choix et que ce choix doit aussi être assumé. Que je sache, Mozilla existe en open-source et même si JS n'est pas GPL, il peut y être intégré. Les standards sont assez clairement définis (mais pas forcément bien suivis) et sont HTML 4.0 et CSS2. JS est une sorte de standard de-facto qui rend des services apréciables. Les plug-in Flash te les applets me paraissent beaucoup plus douteux que quelques misérables lignes de JS. Les browsers que tu évoques ont encore bien plus de problèmes avec ces deux dernières technologies, non ? Ceci dit, ces browsers sont limités dans le support de fonctionalités mais pas forcément pourris; leurs développeurs manqent simplement de ressources pour les mettre à niveau... c'est tout. > Enfin je pense que ca peut etre pratique de le faire en JS, mais alors > au moins laisser une porte de secours alternative JS-free pour ceux > qui ont des problemes ... De quels problèmes veux-tu parler ? Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
On Wed, Aug 28, 2002 at 04:17:17PM +0200, Jean-Bruno Luginbühl wrote: > on peut très bien imaginer dans mon cas (surtout dans mon cas, > puisque je voudrais être multi-plateforme) avoir une application > intranet sans pour autant faire un submit, mais avoir également la > liste qui change, non? La différence ici, c'est que vu que c'est réservé à un Intranet, il n'y aura pas 36 browsers exotiques qui utiliseront le script, donc moins de probleme. Les problemes se posent plus souvent lorsqu'il s'agit de tester un script pour toutes les versions de tous les browsers. La, ca ne serait pas le cas, donc ca me semble faisable. Sinon, ya aussi la possibilité de faire une application ou applet java, donc le comportement est au moins standardisé par java et non pas propre à chaque browsers (ok un applet pour un input ...). -- Sebastien Cevey <[EMAIL PROTECTED]> Cine7 - www.cine7.net Milcis - www.milcis.net ICQ: 48895760 -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
Bonjour, Personnellement actuellement nous avons une application qui lorsque l'on frappe la première lettre, par exemple W, automatiquement l'application complète le nom (WATERPLUG dans ce cas). Et au fure et à mesure que nous tapons les lettre le nom se change pour correspondre aux nouvelles données. Cela est TRES utile, lorsque nous recherchons un produit ou un client (qui est à ce moment là en face de nous en attente de saisie de sa commande), et que nous avons une fenêtre dans laquelle nous tapons les lettres et un tableau situé en dessous avec les noms se modifiants et se mettants correctement en page. Dans notre cas, c'est une application Windev (et une base de donnée Windev locale), mais je vais probablement passer à une base Postgresql avec les mêmes fonctionnalités, et je me vois mal faire dans ce cas une nouvelle requête par une frappe de quelques lettres puis un submit. Je sais, c'est une application locale, qui sera prochainement sur un serveur sql et fonctionnera de la même manière, mais on peut très bien imaginer dans mon cas (surtout dans mon cas, puisque je voudrais être multi-plateforme) avoir une application intranet sans pour autant faire un submit, mais avoir également la liste qui change, non? Jean-Bruno -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
On Wed, Aug 28, 2002 at 03:43:49PM +0200, Daniel Cordey wrote: > Le genre de code JS est hyper simple dans ce genre de situation. Il > n'est pas nécessaire d'accèder à des objets exotiques du > browser. Les codes JS que j'utilise pour ce genre de manipulations > fonctionnent avec toutes les versions de Konqueror, Opera, Netscape > et Mozilla. Je dis ca notamment parce qu'un site assez pratique (www.phpclasses.com) utilise une verification du password en javascript avant de soumettre le formulaire. Ca marche sous IE et NN, mais pas sous Konqueror (enfin la derniere fois que j'ai testé). Ca peut etre un bug du browser ou du script JS, mais dans les 2 cas, pour etre sur de son script, il faudrait tester avec tous les browsers (le mec ayant pas forcément linux). En PHP, si ca marche avec un browser, ca marche aussi avec les autres ... Et meme si on admet que la faute est au browser, dire "bah utilise un browser moins pourri", ca me semble un peu gênant :) Mon exemple relève peut-être plus de l'incompétence du programmeur qu'autre chose, mais ca reste des cas un peu emm.. :) Enfin je pense que ca peut etre pratique de le faire en JS, mais alors au moins laisser une porte de secours alternative JS-free pour ceux qui ont des problemes ... -- Sebastien Cevey <[EMAIL PROTECTED]> Cine7 - www.cine7.net Milcis - www.milcis.net ICQ: 48895760 -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
On 28 Aug 2002, Rafael Muñoz Moreno Davila wrote: > Le problème là dedant c'est que je ne connais pas le vml et n'est jamais Il s'agit de wml: WML is a free and extensible Webdesigner's off-line HTML generation toolkit for Unix. WML consists of a control frontend driving up to nine backends in a sequential pass-oriented filtering scheme. Each backend provides one particular core language. For maximum power WML additionally ships with a well-suited set of include files which provide higher-level features build on top of the backends core languages. While not trivial and idiot proof WML provides most of the core features real hackers always wanted for HTML generation. > utilisé le cvs. Il y a un début à tout! (ce n'est pas indispensable, cependant). > Je pensais au PHP car il me semblais que de mettre 1 ligne pour faire la > connexion avec la base de donnée était plus simple et plus rapide plutot > que de coder en dur la centaine de liens que contiennes mes menus > déroulants. Oui, c'est juste, encore que cela peut se faire statiquement aussi, avec un fichier contenant la liste des liens, et de plus cela ne changera pas la qualité du code reçu par le client WWW. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
On Wed, Aug 28, 2002 at 11:19:49AM +0200, Marc SCHAEFER wrote:
>on a une base de données avec 5000 clients et l'on désire offrir
>une recherche par nom, qui offre également de la `completion'.
>
> Idée 2:
>- on envoie tous les mots différents qui existent. Les mots dont
> les N premières lettres sont identiques sont envoyés en une
> fois, sous forme de trois lettres.
>
> Marc SCHAEFER
> Martial GUEX
> Anne POSSOZ
>
> -> ('Mar', 'Anne POSSOZ') qui peuvent être proposés en JS. Dans le
> premier cas, taper TAB lancera une requête pour N + 3 avec
> 'Mar' comme début.
Je suis pas sur d'avoir compris l'idée 2 là ...
Mais personnellement, j'aurai préféré ici l'alternative server-side
pour plusieurs raisons :
o Le mec qui utilise un browser qui supporte mal JS ou pas du tout
(lynx) sera dispensé d'envoyer un mail d'insulte au webmaster.
o On est donc certain du comportement server-side. Ce n'est pas le cas
chez le client.
o C'est quand meme 10x plus rapide de coder ca en PHP qu'en javascript
(sans compter les heures de test, etc).
Avec les connections actuelles, meme un 56k, on peut raisonnablement
dire qu'un formulaire soumis et une page rechargée ne prend pas un
temps enorme. On peut aussi garder la page très légère pour accelèrer
encore la recharge de la page, voire pire, utiliser des frames.
Mais c'est clair que ce genre de code javascript peut être marrant à
faire, et pourrait être une alternative parallèle à un formulaire
soumis, mais ca me semble un peu "dangereux" de ne jurer que par ca.
> Quelqu'un a-t-il déjà implémenté quelque chose de ce genre ?
Non, et apres quelques recherches sur Google, je n'ai rien trouvé non
plus ...
--
Sebastien Cevey <[EMAIL PROTECTED]>
Cine7 - www.cine7.net
Milcis - www.milcis.net
ICQ: 48895760
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.
Re: Question pratique
Le mer 28/08/2002 à 09:57, Daniel Cordey a écrit : > On Tuesday 27 August 2002 23:39, Rafael Muñoz Moreno Davila wrote: > > > J'ai sur mon site 3 menus déroulants assez conséquents, et j'aimerais > > les remplacer pour que cela sois plus compatible (actuellement en > > javascript) et plus rapide (car les pages font toutes plus de 20k rien > > qu'avec ces 3 menus), je me demandais alors, si c'était mieux de les > > faires en PHP uniquement, ou d'y ajouter du MySQL. Avez vous d'autres > > idées? > > PHP tournera sur ton serveur et construira la page HTML à envoyé au browser. > Dans ce cas, générer l'html en php, ou avoir un fichier en statique ne va pas > changer les performances. Dans tous les cas, tu aura besoin de : > > .. > > Tout au plus, peux-tu envisager d'envoyer un tableau en JS : > > >var Menu1 = new array( 'blanc', 'rouge', noir', ...); >var Menu2 = new array( 'one', two', 'three', ...); > >DisplayMenu(Menu1); >DisplayMenu(Menu2); > > > La fonction DisplayMenu sera chargée de construire le code HTML équivalent à : > > red value='rouge'>rouge... > > Ceci a l'avantage de pouvoir envoyer un codre très compacte au browser et de > laisser celui-ci faire le travail de construction HTML à l'aide d'un > programme JS. Cette une technique que j'utilise souvent losrque je dois > transmettre de grosses pages à la structure HTML complexe. C'est > naturellement particulièrement adapté à la présentation de liste, tablaux, > forms, etc. > > Maintenant, mettre tes données dans une base MySQL est certainement une bonne > chose, mais si tes données ne changent jamais, ce n'est pas forcément > indispensable. Ça dépend de plusieurs autres critères. > > Si tes données sont dans une base SQL, avoir un programme PHP pour les > récupérer et les envoyer au browser (HTML ou JS, peut importe) est logique. > > Daniel Salut! Certains peuvent changer et d'autres pas. Dans un autre ordre d'idée, j'ai aussi un slideshow sur mon site, que j'ai fais en javascript. le concept est que j'ai deux images en forme de flèches et lorsque l'on clique dessus (OnClick) ça ne change que l'image qu'il y a à l'interieure du tableau, et ainsi n'a pas besoin de recharger une page differente à chaque fois. Maintenant ma question est: est ce que dans ce cas là, ou il va y a voir du changement (rajouter et enlever des images). Quelle serait la meilleure méthode. Moi j'avais de nouveau pensé à PHP MySQL pour la compatibilité, car j'ai eu des visiteurs qui ne pouvais pas utiliser le slideshow à cause que c'était fait en javascript. Merci et à toute! -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
Le mer 28/08/2002 à 09:31, Marc SCHAEFER a écrit : > On 27 Aug 2002, Rafael Muñoz Moreno Davila wrote: > > > J'ai sur mon site 3 menus déroulants assez conséquents, et j'aimerais > > les remplacer pour que cela sois plus compatible (actuellement en > > javascript) et plus rapide (car les pages font toutes plus de 20k rien > > qu'avec ces 3 menus), je me demandais alors, si c'était mieux de les > > faires en PHP uniquement, ou d'y ajouter du MySQL. Avez vous d'autres > > idées? > > PHP et MySQL étant respectivement un langage permettant de générer du HTML > (voire du Javascript) pour exécution par le client WWW, et une base de > données permettant de stocker ce que l'on veut, je ne vois pas trop le > rapport avec du code HTML léger et propre. > > Pour rendre du code HTML léger et propre, l'écrire à la main (avec vi, ou > avec un générateur via du PHP). On n'a jamais fait mieux. > > En règle générale, sauf pour un serveur à fort contenu dynamique (p.ex. > chaque utilisateur du serveur WWW peut configurer l'interface du serveur > en ajoutant et enlevant des menus), du HTML statique suffit amplement. > Cela sera plus rapide, plus simple, et plus sûr. > > Rien n'empêche de générer, malgré tout, ce HTML statique depuis une base > de données, avec des fichiers d'inclusions, et même en Perl et PHP: mais > le fichier résultant sera un simple fichier HTML. > > Ma méthode: > >- j'écris tout le code HTML à la main, avec commentaires parfois, > et mise en page lisible. > >- ce code est testé, morceau par morceau avec un validateur > (http://validator.w3.org/) > >- je combine ce code via inclusions statiques (similaire à des > #include en C) grâce à l'outil wml: en général un header, > un footer et une partie `mobile' suffit. Le header et le footer > sont paramétrés (variables modifiables à l'inclusion: on peut > voir cela comme un template). > >- au final je teste chaque fichier (page) statique avec le > validateur. > >- les fichiers sources (pas les fichiers résultants du passage de wml) > sont gérés dans un CVS. > > Ce qui précède suppose également aucune paramétrisation de la part de > l'utilisateur, un changement du contenu du site toutes les quelques > minutes au plus, et aucune utilisation de balises ou code spécifique à un > navigateur. > > On pourrait très bien changer cette génération statique par une génération > dynamique: faisant ce que wml fait dans un script PHP, en stockant le > header, le footer, les données et les paramètres dans une base de données. > > Mais en général (sauf, encore une fois, pour des serveurs WWW dont la > présentation doit être paramétrable par l'utilisateur, ou qui utilisent > des trucs dépendants du client WWW) le dynamique n'apporte rien. Salut! Le problème là dedant c'est que je ne connais pas le vml et n'est jamais utilisé le cvs. Je pensais au PHP car il me semblais que de mettre 1 ligne pour faire la connexion avec la base de donnée était plus simple et plus rapide plutot que de coder en dur la centaine de liens que contiennes mes menus déroulants. Bye! -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
On Wed, 28 Aug 2002, Daniel Cordey wrote:
> Exellente discipline. Donc, si l'on désire suivre cette méthode, le JS se
> trouve hors-circuit d'entrée :-)
non, mais j'essaierais de séparer le plus possible les fonctionnalités
JS des fonctionnalités HTML, et de rendre si possible la plupart
des fonctionnalités JS faisables en HTML.
Par contre, je suis d'accord que le JS peut amener un gain de
productivité acceptable, p.ex. pour avertir l'utilisateur avant
de surcharger le serveur avec une requête invalide ... mais pas
comme unique filtre de données.
Une autre application intéressante du JS pourrait être, au lieu de donner
un SELECT énorme (genre tous les pays, ou tous les clients), un raccourci
hiérarchique. Je m'explique:
on a une base de données avec 5000 clients et l'on désire offrir
une recherche par nom, qui offre également de la `completion'.
Idée 1:
- on envoie tous les noms au script JavaScript et celui-ci fait
la completion.
Idée 2:
- on envoie tous les mots différents qui existent. Les mots dont
les N premières lettres sont identiques sont envoyés en une
fois, sous forme de trois lettres.
Marc SCHAEFER
Martial GUEX
Anne POSSOZ
-> ('Mar', 'Anne POSSOZ') qui peuvent être proposés en JS. Dans le
premier cas, taper TAB lancera une requête pour N + 3 avec
'Mar' comme début.
Ce genre d'application sont, à mon avis, des applications utiles de
JavaScript: elles apportent un gain de temps appréciable, et des
fonctionnalités normalement seulement disponibles aux applications
locales. Mais une alternative simple existe: demander de taper quelques
lettres puis submit et on fait une recherche en retournant ce qu'il faut.
Cela peut suffire et cela n'utilise pas le JS.
Quelqu'un a-t-il déjà implémenté quelque chose de ce genre ?
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.
Re: Question pratique
On Wednesday 28 August 2002 09:31, Marc SCHAEFER wrote: > >- ce code est testé, morceau par morceau avec un validateur > (http://validator.w3.org/) >- au final je teste chaque fichier (page) statique avec le > validateur. > Exellente discipline. Donc, si l'on désire suivre cette méthode, le JS se trouve hors-circuit d'entrée :-) Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
On 27 Aug 2002, Rafael Muñoz Moreno Davila wrote: > J'ai sur mon site 3 menus déroulants assez conséquents, et j'aimerais > les remplacer pour que cela sois plus compatible (actuellement en > javascript) et plus rapide (car les pages font toutes plus de 20k rien > qu'avec ces 3 menus), je me demandais alors, si c'était mieux de les > faires en PHP uniquement, ou d'y ajouter du MySQL. Avez vous d'autres > idées? PHP et MySQL étant respectivement un langage permettant de générer du HTML (voire du Javascript) pour exécution par le client WWW, et une base de données permettant de stocker ce que l'on veut, je ne vois pas trop le rapport avec du code HTML léger et propre. Pour rendre du code HTML léger et propre, l'écrire à la main (avec vi, ou avec un générateur via du PHP). On n'a jamais fait mieux. En règle générale, sauf pour un serveur à fort contenu dynamique (p.ex. chaque utilisateur du serveur WWW peut configurer l'interface du serveur en ajoutant et enlevant des menus), du HTML statique suffit amplement. Cela sera plus rapide, plus simple, et plus sûr. Rien n'empêche de générer, malgré tout, ce HTML statique depuis une base de données, avec des fichiers d'inclusions, et même en Perl et PHP: mais le fichier résultant sera un simple fichier HTML. Ma méthode: - j'écris tout le code HTML à la main, avec commentaires parfois, et mise en page lisible. - ce code est testé, morceau par morceau avec un validateur (http://validator.w3.org/) - je combine ce code via inclusions statiques (similaire à des #include en C) grâce à l'outil wml: en général un header, un footer et une partie `mobile' suffit. Le header et le footer sont paramétrés (variables modifiables à l'inclusion: on peut voir cela comme un template). - au final je teste chaque fichier (page) statique avec le validateur. - les fichiers sources (pas les fichiers résultants du passage de wml) sont gérés dans un CVS. Ce qui précède suppose également aucune paramétrisation de la part de l'utilisateur, un changement du contenu du site toutes les quelques minutes au plus, et aucune utilisation de balises ou code spécifique à un navigateur. On pourrait très bien changer cette génération statique par une génération dynamique: faisant ce que wml fait dans un script PHP, en stockant le header, le footer, les données et les paramètres dans une base de données. Mais en général (sauf, encore une fois, pour des serveurs WWW dont la présentation doit être paramétrable par l'utilisateur, ou qui utilisent des trucs dépendants du client WWW) le dynamique n'apporte rien. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Question pratique
On Tuesday 27 August 2002 23:39, Rafael Muñoz Moreno Davila wrote: > J'ai sur mon site 3 menus déroulants assez conséquents, et j'aimerais > les remplacer pour que cela sois plus compatible (actuellement en > javascript) et plus rapide (car les pages font toutes plus de 20k rien > qu'avec ces 3 menus), je me demandais alors, si c'était mieux de les > faires en PHP uniquement, ou d'y ajouter du MySQL. Avez vous d'autres > idées? PHP tournera sur ton serveur et construira la page HTML à envoyé au browser. Dans ce cas, générer l'html en php, ou avoir un fichier en statique ne va pas changer les performances. Dans tous les cas, tu aura besoin de : .. Tout au plus, peux-tu envisager d'envoyer un tableau en JS : var Menu1 = new array( 'blanc', 'rouge', noir', ...); var Menu2 = new array( 'one', two', 'three', ...); DisplayMenu(Menu1); DisplayMenu(Menu2); La fonction DisplayMenu sera chargée de construire le code HTML équivalent à : redrouge... Ceci a l'avantage de pouvoir envoyer un codre très compacte au browser et de laisser celui-ci faire le travail de construction HTML à l'aide d'un programme JS. Cette une technique que j'utilise souvent losrque je dois transmettre de grosses pages à la structure HTML complexe. C'est naturellement particulièrement adapté à la présentation de liste, tablaux, forms, etc. Maintenant, mettre tes données dans une base MySQL est certainement une bonne chose, mais si tes données ne changent jamais, ce n'est pas forcément indispensable. Ça dépend de plusieurs autres critères. Si tes données sont dans une base SQL, avoir un programme PHP pour les récupérer et les envoyer au browser (HTML ou JS, peut importe) est logique. Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Question pratique
Bonjour tout le monde! J'ai sur mon site 3 menus déroulants assez conséquents, et j'aimerais les remplacer pour que cela sois plus compatible (actuellement en javascript) et plus rapide (car les pages font toutes plus de 20k rien qu'avec ces 3 menus), je me demandais alors, si c'était mieux de les faires en PHP uniquement, ou d'y ajouter du MySQL. Avez vous d'autres idées? Merci! A bientot! -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
