J'ai des pages Web qui effectuent des traitements asynchrones lors de la
validation de leur formulaires.
Une fois le formulaire validé, j'affiche une DIV en haut à droite du
navigateur pour indiquer l'état du traitement. Cependant, la page peut être
revalidée ou les champs modifiés.
Je désactive donc les contrôles du formulaire via disabled. Cependant, je
suis *fatigué* de devoir coder tout ça pour chaque page.
Est-il possible d'écrire une fonction générique désactivant tous les INPUT
(textbox, textarea, radiobutton, checkbox, etc) ? Genre, elle parcourt tous
les contrôles de la page et les désactive...
Autre question : pensez-vous qu'il soit judicieux de désactiver aussi les
liens ?
ici "privVar" est une variable inaccessible en dehors de myobj, donc privée, mais myobj expose des "méthodes" publiques pour y accéder dans le return {} final.
myobj.set(25); alert(myobj.get()); // == 25
Désolé, j'ai pas les mots corrects pour bien expliquer comment ça marche, le mieux c'est de se laisser guider par google toujours sur "javascript module pattern"
-- laurent
En réponse à Laurent vilday qui écrivit, en date du : 18/08/07 3:36, le
message suivant :
var gestionnaire = function()
{
var active = null;
return {
show:function()
{
active = document.createElement('div');
....
document.body.appendChild(active);
},
hide:function{}
{
document.body.removeChild(active);
ici "privVar" est une variable inaccessible en dehors de myobj, donc
privée, mais myobj expose des "méthodes" publiques pour y accéder dans
le return {} final.
myobj.set(25);
alert(myobj.get()); // == 25
Désolé, j'ai pas les mots corrects pour bien expliquer comment ça
marche, le mieux c'est de se laisser guider par google toujours sur
"javascript module pattern"
ici "privVar" est une variable inaccessible en dehors de myobj, donc privée, mais myobj expose des "méthodes" publiques pour y accéder dans le return {} final.
myobj.set(25); alert(myobj.get()); // == 25
Désolé, j'ai pas les mots corrects pour bien expliquer comment ça marche, le mieux c'est de se laisser guider par google toujours sur "javascript module pattern"
-- laurent
Laurent vilday
En réponse à Laurent vilday qui écrivit, en date du : 18/08/07 3:49, le message suivant :
mais c'est rien comparé à ce "javascript:" que je ne saurais voir, c'est trop laid.
Manque plusieurs variables non déclarées qui polluent le scope global. Plus les deux variables (windowWidth et windowHeight) déclarées en plein milieu de la fonction, c'est pas très très propre :) A défaut de propreté du code (somme toute relative dès qu'on parle javascript), j'ai pris l'habitude, et je pense sincèrement que c'est une bonne habitude, de déclarer absolument *toutes* mes variables en début de block, ça évite les surprises des variables qui ne sont pas dans le bon scope d'éxécution.
var xScroll, yScroll, pageWidth, pageHeight, windowWidth, windowHeight;
[cut]
arrayPageSize = new Array(pageHeight, pageWidth, windowHeight, windowWidth); return arrayPageSize;
autant retourner directement le tableau sans créer de variable intermédiaire, d'autant qu'on vient de voir qu'elle polluait :)
Par contre, on voit le DIV noir avant que la transparence lui soit appliqué... c'est possible de faire qqchose ?
Peut être à cause du blockDiv = document.createElement('blockDiv');
parce que ça existe pas l'élément HTML <blockDiv> :)
Toujours sur blockDiv (mais la variable JS cette fois), elle est déclarée dans l'objet jsTopLoaderAjax (jsTopLoaderAjax.blockDiv) hors en faisant
blockDiv = docu.....;
ça va créer une variable globale - puisque pas de var devant - au lieu d'utiliser la propriété de l'objet (désolé pour le vocabulaire, ca s'appelle peut être pas une propriété, désolé les puristes)
Donc faudrait faire : jsTopLoaderAjax.blockDiv = docu....;
Comme ça, pas de pollution du scope global.
Sinon, je vois que "showLoader" et "hideLoader" font toutes les deux appels en permanence au même D::gEBI('topLoader'); Peut être (j'en sais rien) serait-il préférable de garder une référence une fois trouvée au lieu d'aller la rechercher à chaque fois.
Pareil (ou presque) pour "showBlockDiv" et "hideBlockDiv" dans l'un (showBlockDiv) l'élément "blockDiv" n'arrete pas de se récréer et dans l'autre il arrête pas d'être nullifier. Peut être (encore une fois j'en sais rien) serait-il toujours préférable de garder la référence une fois crée et l'insérée/supprimée au besoin.
Et BTW, pourquoi avoir créé les fonctions "showBlockDiv" et "hideBlockDiv" ? Elle semblent faire doublon (au vu du nommage et du code) en ayant un rôle complètement similaire à "showLoader" et "hideLoader". J'aurais tendance à ne pas séparer des fonctions interdépendantes.
var jsTopLoaderAjax = function() { // variable privée var handle, // pour ceux que ça intéresse, // même si c'est pas indispensable // de faire comme ça :D // "javascript lazy pattern" getBlockDiv = function() { var div = document.createElement('div'); div.onclick = function() { return false; }; div.style..... // sauf le style.height getBlockDiv = function() { return div; }; return getBlockDiv(); }; // function privée function getPageInfo() { // copié/collé de la méthode originale // si elle convient } // interface publique return { show:function() { var div = getBlockDiv(); handle = handle || document.getElementById('topLoader'); div.style.height = getPageInfo()[0] + 'px'; document.body.appendChild(div); handle.style.display = 'block'; }, hide:function() { if ( !handle ) { return ; } handle.style.display = 'none'; document.body.removeChild(getBlockDiv()); } }; }(); // auto invocation de la fonction
Manque plusieurs variables non déclarées qui polluent le scope global.
Plus les deux variables (windowWidth et windowHeight) déclarées en plein
milieu de la fonction, c'est pas très très propre :) A défaut de
propreté du code (somme toute relative dès qu'on parle javascript), j'ai
pris l'habitude, et je pense sincèrement que c'est une bonne habitude,
de déclarer absolument *toutes* mes variables en début de block, ça
évite les surprises des variables qui ne sont pas dans le bon scope
d'éxécution.
var
xScroll, yScroll,
pageWidth, pageHeight,
windowWidth, windowHeight;
[cut]
arrayPageSize = new Array(pageHeight, pageWidth,
windowHeight, windowWidth);
return arrayPageSize;
autant retourner directement le tableau sans créer de variable
intermédiaire, d'autant qu'on vient de voir qu'elle polluait :)
Par contre, on voit le DIV noir avant que la transparence lui soit
appliqué... c'est possible de faire qqchose ?
Peut être à cause du
blockDiv = document.createElement('blockDiv');
parce que ça existe pas l'élément HTML <blockDiv> :)
Toujours sur blockDiv (mais la variable JS cette fois), elle est
déclarée dans l'objet jsTopLoaderAjax (jsTopLoaderAjax.blockDiv) hors en
faisant
blockDiv = docu.....;
ça va créer une variable globale - puisque pas de var devant - au lieu
d'utiliser la propriété de l'objet (désolé pour le vocabulaire, ca
s'appelle peut être pas une propriété, désolé les puristes)
Donc faudrait faire :
jsTopLoaderAjax.blockDiv = docu....;
Comme ça, pas de pollution du scope global.
Sinon, je vois que "showLoader" et "hideLoader" font toutes les deux
appels en permanence au même D::gEBI('topLoader'); Peut être (j'en sais
rien) serait-il préférable de garder une référence une fois trouvée au
lieu d'aller la rechercher à chaque fois.
Pareil (ou presque) pour "showBlockDiv" et "hideBlockDiv" dans l'un
(showBlockDiv) l'élément "blockDiv" n'arrete pas de se récréer et dans
l'autre il arrête pas d'être nullifier. Peut être (encore une fois j'en
sais rien) serait-il toujours préférable de garder la référence une fois
crée et l'insérée/supprimée au besoin.
Et BTW, pourquoi avoir créé les fonctions "showBlockDiv" et
"hideBlockDiv" ? Elle semblent faire doublon (au vu du nommage et du
code) en ayant un rôle complètement similaire à "showLoader" et
"hideLoader". J'aurais tendance à ne pas séparer des fonctions
interdépendantes.
var jsTopLoaderAjax = function()
{
// variable privée
var
handle,
// pour ceux que ça intéresse,
// même si c'est pas indispensable
// de faire comme ça :D
// "javascript lazy pattern"
getBlockDiv = function()
{
var div = document.createElement('div');
div.onclick = function() { return false; };
div.style..... // sauf le style.height
getBlockDiv = function() { return div; };
return getBlockDiv();
};
// function privée
function getPageInfo()
{
// copié/collé de la méthode originale
// si elle convient
}
// interface publique
return {
show:function()
{
var div = getBlockDiv();
handle = handle || document.getElementById('topLoader');
div.style.height = getPageInfo()[0] + 'px';
document.body.appendChild(div);
handle.style.display = 'block';
},
hide:function()
{
if ( !handle ) { return ; }
handle.style.display = 'none';
document.body.removeChild(getBlockDiv());
}
};
}(); // auto invocation de la fonction
Manque plusieurs variables non déclarées qui polluent le scope global. Plus les deux variables (windowWidth et windowHeight) déclarées en plein milieu de la fonction, c'est pas très très propre :) A défaut de propreté du code (somme toute relative dès qu'on parle javascript), j'ai pris l'habitude, et je pense sincèrement que c'est une bonne habitude, de déclarer absolument *toutes* mes variables en début de block, ça évite les surprises des variables qui ne sont pas dans le bon scope d'éxécution.
var xScroll, yScroll, pageWidth, pageHeight, windowWidth, windowHeight;
[cut]
arrayPageSize = new Array(pageHeight, pageWidth, windowHeight, windowWidth); return arrayPageSize;
autant retourner directement le tableau sans créer de variable intermédiaire, d'autant qu'on vient de voir qu'elle polluait :)
Par contre, on voit le DIV noir avant que la transparence lui soit appliqué... c'est possible de faire qqchose ?
Peut être à cause du blockDiv = document.createElement('blockDiv');
parce que ça existe pas l'élément HTML <blockDiv> :)
Toujours sur blockDiv (mais la variable JS cette fois), elle est déclarée dans l'objet jsTopLoaderAjax (jsTopLoaderAjax.blockDiv) hors en faisant
blockDiv = docu.....;
ça va créer une variable globale - puisque pas de var devant - au lieu d'utiliser la propriété de l'objet (désolé pour le vocabulaire, ca s'appelle peut être pas une propriété, désolé les puristes)
Donc faudrait faire : jsTopLoaderAjax.blockDiv = docu....;
Comme ça, pas de pollution du scope global.
Sinon, je vois que "showLoader" et "hideLoader" font toutes les deux appels en permanence au même D::gEBI('topLoader'); Peut être (j'en sais rien) serait-il préférable de garder une référence une fois trouvée au lieu d'aller la rechercher à chaque fois.
Pareil (ou presque) pour "showBlockDiv" et "hideBlockDiv" dans l'un (showBlockDiv) l'élément "blockDiv" n'arrete pas de se récréer et dans l'autre il arrête pas d'être nullifier. Peut être (encore une fois j'en sais rien) serait-il toujours préférable de garder la référence une fois crée et l'insérée/supprimée au besoin.
Et BTW, pourquoi avoir créé les fonctions "showBlockDiv" et "hideBlockDiv" ? Elle semblent faire doublon (au vu du nommage et du code) en ayant un rôle complètement similaire à "showLoader" et "hideLoader". J'aurais tendance à ne pas séparer des fonctions interdépendantes.
var jsTopLoaderAjax = function() { // variable privée var handle, // pour ceux que ça intéresse, // même si c'est pas indispensable // de faire comme ça :D // "javascript lazy pattern" getBlockDiv = function() { var div = document.createElement('div'); div.onclick = function() { return false; }; div.style..... // sauf le style.height getBlockDiv = function() { return div; }; return getBlockDiv(); }; // function privée function getPageInfo() { // copié/collé de la méthode originale // si elle convient } // interface publique return { show:function() { var div = getBlockDiv(); handle = handle || document.getElementById('topLoader'); div.style.height = getPageInfo()[0] + 'px'; document.body.appendChild(div); handle.style.display = 'block'; }, hide:function() { if ( !handle ) { return ; } handle.style.display = 'none'; document.body.removeChild(getBlockDiv()); } }; }(); // auto invocation de la fonction
-- laurent
Delf
Laurent vilday vient de nous annoncer :
Manque plusieurs variables non déclarées qui polluent le scope global. [...]
Ouais... remarques pertinentes, va falloir que je regarde ç de plus près dès que j'en aurai le temps... déménagement...
Merci.
-- Delf
Laurent vilday vient de nous annoncer :
Manque plusieurs variables non déclarées qui polluent le scope global.
[...]
Ouais... remarques pertinentes, va falloir que je regarde ç de plus
près dès que j'en aurai le temps... déménagement...