yvanoph
|
|
« Répondre #6 le: Ven. 20 Novembre 2015 à 14:57:28 » |
|
Bon, pris le temps plusieurs fois de visiter votre Page, mais comme d'habitude, en "Version sous marin" comme je disais autrefois...
Le premier constat est qu'il est grand dommage que je n'ai fini de mettre à jour votre Maquette, car vous allez comprendre de suite ! Ci dessous les [Elément]s, nommés "objet"s par XWebDesignor, tel que je les ai trouvés dans votre Code :
obj10000 à obj10027 puis
obj9000 à obj9005 puis
obj8000 à obj8009 puis
obj7005 à obj7008 puis
obj11004 à obj11027.
Comprendre par là que ce sont les [Composant]s visibles pour la majorité affichant quelque chose ? Car si vous regardez tout le Code dans son ensemble, vous remarquerez qu'il est parsemé de ci de là de "<script>"s et autres comme "<img>"s par exemple...
La classe "11???" représente le Contenu réel de la Page, ce qui change de l'une à l'autre puisque chaque Page a son Contenu spécifique ? Mais les classes "7???" à "10???" représentent à elles seules tous les fonds, et là, nous n'en avons pas du tout la Maîtrise ! ! !
Pour mémoire, il convient de rappeler que XWebDesignor a été créé dans l'esprit de permettre au nuléophyte de créer et publier un Site Internet FONCTIONNEL et conforme aux Normes actuelles, ce qu'il remplit fort bien en grande majorité ? Et pour ce faire, il permet donc d'empiler des sous couches via des Pages dites de Fond, afin de simplifier la construction dès que nous avons des [Composant]s répétitifs ? Cette Astuce très pratique présente aussi ses limites, sur lesquelles nous ne pouvons intervenir. D'où les défauts suivants si je transforme ces classes en actions sur la Page :
Classe "10???" : Tous les Boutons répétitifs puisque la dernière Page dite de Fond,
Classe "9???" : des Images et Textes répétitifs communs au Type de Page à construire,
Classe "8???" : des fonds spécifiques au type de Page à construire,
Classe "7???" : Les "<meta>"s spécifiques au Référencement et autres suivis de "<script>"s divers dont ceux générés par XWD et enfin les fonds colorés principaux.
Soyons honnête, je n'ai pas pris le temps de détailler le contenu de chaque Eléments, aussi mon classement ci dessus n'est que ma déduction personnelle logique des empilages et non une affirmation certaine de votre mode de construction !
A la simplicité de ce genre de construction s'oppose un ILLOGISME énorme et très pénalisant quant à une optimisation du chargement et, vous ne le savez pas encore, au passage au Mode dit "responsive" ! ! ! (Nous verrons plus loin...)
En "bonne logique", XWebDesignor au moment de la construction de la Page prend la première Page de Fond qu'il trouve dans ladite Page à afficher et en extrait le Code PUIS regarde si cette Page elle même contient une Page de SOUS fond et va alors en chercher le Code pour l'ajouter et ainsi de suite... De mémoire, nous pouvons ainsi ajouter jusqu'à quatorze sous couches...
En bonne logique aussi, tout ce qui est LU après un autre Elément est affiché "ensuite", donc en théorie par dessus, mais, en jouant sur les "z-index" via le css, il est passé en dessous, d'où un Code dans la Page totalement à l'envers ET illogique, alors qu'un affichage correct pour le Visiteur ?
Nous nous retrouvons donc avec en première ligne d'affichage les Boutons communs, puis les fonds et en TOUT DERNIER le Contenu... Bien sûr, vous ne vous en rendez pas compte si tout passe rapidement par le tuyau, avec une bonne bande passante, alors que dès que nous sommes en heure de pointe, donc en surcharge réseau et pire avec un mauvais Wi Fi, là l'affichage est totalement défectueux, sauf à patienter ?
Bon, donc de façon plus rapide, vous avez construit selon le Modèle de la Maquette initiale (Cf. première Image ci dessous, le "Gestionnaire de Page", avec PLUS de DIX "Pages de Fond" !), avec des empilages comme fonds principaux PUIS fonds spécifiques aux types de Pages PUIS Boutons communs ! Ce mode de construction est utilisé au départ, généralement pour bâtir un Contenu en deux ou trois Colonnes ? Mais comme il présente les défauts suscités, la Maquette définitive devient après compression beaucoup plus simple ? (Cf. deuxième Image ci dessous, "Gestionnaire de Page", avec seulement TROIS réelles "Pages de Fonds" ?)
A noter que nous n'avons alors que DEUX Pages de fond, une intitulée "Deux Colonnes", l'autre "Trois colonnes", et une "Boutons" ! Cette dernière n'est d'ailleurs appelée NULLE PART ! ! ! Elle ne sert qu'à avoir tous les Boutons répétitifs prêts à être employés et parfaitement paramétrés exceptés les Liens pour certains !
Dit autrement, sont appelées dans les Pages actives, visibles, QUE le Modèle "deux" (Cf. deuxième Image) ou "trois" (Cf. troisième Image) colonnes... Et en publication, ça va nous donner TOUS les Fonds, PUIS tous les Contenus ? Mais tel que SANS aucun Lien NI Boutons... Néanmoins, c'est un ordre PARFAITEMENT LOGIQUE, parfaitement construit, et SURTOUT parfaitement modifiable ensuite SI application du "responsive" ?
Et pour finir cette Page, nous allons dans le Modèle "Boutons" (Cf. quatrième Image), TOUT copier puis TOUT coller dans notre Page active ! A ce moment, les Boutons utiles restent, tous ceux à supprimer le sont, les JSCs de css sont tabulés en premières lignes par un "Tout en arrière" et les Liens dans les Boutons actualisés quant aux Pages visées voire les Contenus et Info Bulles actualisés aussi ?
Astuce :
A noter que la Page dite "Boutons" contient AUSSI, outre les Boutons conventionnels, TOUS les JSCs "XWD en CMS", les Boutons à effets PUIS les Animations, les "<script>"s de Compteur ou autres comme le JSC "The End" etc., PARFAITEMENT "tabulés" ? Il est quand même plus facile de "tabuler" une Page "légère" qu'une Page complète ? ? ? Et au collage, ne restera à faire que : SUPPRIMER les ajouts inutiles, ce qui ne perturbe PAS XWD, COMPLETER les ajouts par les bonnes valeurs, comme pour le "<script>" du Moostik par exemple, TABULER en UN Clic chaque JSCs "XWD en CMS" en tout premier...
GROS avantage, tout sera "tabulé" en bonne place, tout sera SURTOUT chargé en BON ordre LOGIQUE, à savoir les Fonds, les Contenus Textes, les Contenus Images, les Animations, les Boutons, les fonctions diverses en peu de Clics ?
Et même prêt au passage en "responsive" ultérieurement ?
BON, cette technique essentielle de Mode de Construction établie, juste deux à trois choses qui m'ont surpris...
Vous avez choisi comme Code, Valeur de Variable le chiffre 100000, qui correspond à rouge brun presque noir, qui ne correspond pas "à première vue", à la colorimétrie de la Page, aussi une raison particulière ? Mais si c'est assez explicite pour vous, pourquoi pas puisque parfaitement fonctionnel et correct en langage informatique !
Hors cette curiosité personnelle, des Liens coupés qui alourdissent le Code... (Cf. cinquième Image) C'est un défaut trouvé un peu partout, je veux dire par là chez gb87 aussi (Publication à venir !), qui provient de la mauvaise gestion de Windows par XWD... Le Code suivant :
<p class="xwd56" style="line-height: 12pt;"> <span class="xwd74" style="line-height: 10pt;">1</span> <span class="xwd74" style="line-height: 10pt;"> 584 hab Alt : 319 à 690 m</span> </p>
devrait être :
<p class="xwd56" style="line-height: 12pt;"> <span class="xwd74" style="line-height: 10pt;">1 584 hab Alt : 319 à 690 m</span> </p>
Même résultat à l'affichage, mais BEAUCOUP MOINS de poids ? ? ?
Alors l'astuce consiste à copier l'intégralité du Texte du Lien dans "NotePad", SUPPRIMER le tout dans XWebDesignor, compacter etc. TROIS fois puis copier le Texte de "NotePad" dans XWD et créer l'intégralité du Lien d' UN SEUL COUP ! Sinon XWD NE SACHANT PAS COMPACTER un Lien dans sa Base de données, il le conservera en X morceaux...
Et en parlant de poids, EXCELLENT en ce qui concerne votre Page ? (Cf. dernière Image ci dessous !) En effet, QUE 180 Ko tout compris à l'affichage initial ! ! ! Qui passera à 400 SI le Visiteur demande à afficher les Images en grand, donc PARFAIT ?
Néanmoins, des "Vignettes" à 20 Ko, la ça coince ? D'autant que l'Image "Normale" au dessus elle ne pèse comparativement que 23 ? Problème de compression à régler ?
Et pour clore cette longue réponse, un problème de "<script>", du à une fonction absente, suite à l'écrasement d'un fichier important... Nous n'allons pas corriger de suite ce détail, qui disparaitra probablement une fois tout replacé dans le bon ordre au chargement ? D'autant qu'il me faux vous faire passer l'ensemble des JSCs et JSCXs aux "dernières Normes"...
En résumé, point d' "engueulade" en vue donc, juste un Mode de Construction à revisiter tout simplement par méconnaissance d'XWebDesignor et surtout ses pièges ?
Cordialement, Yvanoph---
|