Brols de Killan

#%ù$*§ de bug javascript !!!

Reprenons… j’en suis à la gestion des pages (existantes, nouvelles, supprimées), du menu et du reste (non menu).

Jusque là on reçoit, on manipule et depuis hier on prépare les données pour envoie et impacte.

La réception est en json, décodé via jquery, on récupère des tableaux associatifs imbriqués.

Je prépare donc un tableau et comme index de clef je veux mettre, non pas un id (cas classique), mais un ‘mot’.

J’envoie et j’imprime ce que je reçois : du vide. Si id numérique, je reçois ce qui est attendu mais non conforme avec mes attentes.

Donc faux et archi faux, je ne reçois pas un tableau, Firebug m’a menti, le méchant. Je reçois un objet et chaque élément contenant un autre par une clef est un objet et non un tableau.

Sur base de cela, l’envoie a pu fonctionner complètement.

Dit comme cela ça parait évident ou du moins ça l’aurait été pour un fin connaisseur de la mécanique de base de javascript. Mais face à un code « bon », sans erreur évidente, on cherche non pas une erreur de type (javascript ne l’est pas), on cherche l’erreur de syntaxe une fois l’erreur de logique écartée.

3h pour obtenir le bon résultat et une dizaine de plantages de Firefox qui n’aime pas qu’on débug longuement le javascript. Va comprendre le debuger n’aimant pas debuger…

On y est, nerfs à vif, content d’avoir trouvé, épuisé et se disant que demain on remet les mains dedans pour cette fois impacter ce que l’on a reçus…

Programme de la suite

– Poursuivre l’éditeur (gras, italique, styles et blocs spéciaux)
– Définir les contenus secondaires (~bordures, arianes, …)
– Installer le site mère
– Installer RACO
– Installer photo véro

—
t+=5h=152h;

Le gestionnaire des pages a été fait, puis défait pour être refait, au final ça avance sans reculer tout en se complétant.

Une chose faite donne une dizaine d’ajouts à prévoir et à coder… Mais j’y arriverai !

Certes je suis en retard sur mon désire de le faire en 3 mois, certes j’ai également traîner et eu des imprévus, cela n’empêche que cela avance dans le bon sens et concrètement.

Programme de la suite

– Poursuivre l’éditeur (gras, italique, styles et blocs spéciaux)
– Définir les contenus secondaires (~bordures, arianes, …)
– Installer le site mère
– Installer RACO
– Installer photo véro

—
t+=9h=147h;

Le système de gestion de pages est en cours. Le plus dur n’étant pas le système mais l’ergonomie, l’utilisabilité.

Qu’est-ce qui doit être visible au niveau des ‘helper’, comment doit régir l’interface au moment du glisser/déplacer. Questions pertinentes mais qui font perdre un de ces temps.

Une fois que l’infographiste aura mis la seconde couche sur mon travail ça sera peut-être encore mieux.

La suite c’est la sauvegarde, l’édition des infos et la création de page.

Programme de la suite

– Poursuivre l’éditeur (gras, italique, styles et blocs spéciaux)
– Finir le design des menus
– Définir les contenus secondaires (bordures, arianes, …)
– Installer le site mère
– Installer x nouveaux Buzz

—
t+=5h30=138h;

Les listes aussi peuvent vouloir être complétée, donc il faut une insertion et des tag en plus à ce niveau. Cela a demandé de revoir certains blocs de code et cela a aussi mis en évidence quelques erreurs toutes corrigées.

Une panoplie de fonctions utilitaires se construit. Le travail, je l’espère, devrait appeler de plus en plus abstraitement ces fonctions. ainsi augmentant la rapidité d’avancement.

Plus on avance, plus il y a du travail, neuf et restant. Mais ça avance.

Programme de la suite

– Poursuivre l’éditeur (gras, italique, styles et blocs spéciaux)
– Finir le design des menus
– Définir les contenus secondaires (bordures, arianes, …)
– Gestion des pages
– Installer le site mère
– Installer x nouveaux Buzz

—
t+=3h=132h30;

Prenez un paragraphe fraichement ajouté et décidez d’en faire un titre. Voilà l’idée et elle fonctionne. Un simple clic et un choix vous donnent le bon résultat.

Plus complexe et sans filet, convertir un élément en liste et inversement fonctionne également. L’astuce est que si vous convertissez une liste en titre, le premier élément sera le titre et les autres des paragraphes.

Cela a demandé d’écrire quelques fonctions de manipulation qui permettent d’avoir la main sur la structure du contenu. L’avenir devrait être plus simple :).

Programme de la suite

– Poursuivre l’éditeur (gras, italique, styles et blocs spéciaux)
– Finir le design des menus
– Définir les contenus secondaires (bordures, arianes, …)
– Installer le site mère
– Installer x nouveaux Buzz

—
t+=3h=129h30;

Le but est d’arriver aujourd’hui à présenter une insertion de données (texte : paragraphe) en fin ou milieu de zone et également de le supprimer. C’est chose faite mais ce fut dur !

Autre point, la gestion d’événement concernant le helper d’indication d’action d’édition possible. Moi j’ai juste envie de le supprimer et d’indiquer au gens d’utiliser leur clic droit contextuellement, ce qui là va très bien.

À la va vite, une première version des fenêtres du menu principale. elle est vide mais le contexte montre clairement l’idée.

Plus on avance plus il y a des chose à faire… c’est affolant, stressant, tracassant, mais j’y arriverai.

S’en suit l’édition de l’existant, la modification de type (titre, liste), l’insertion plus contextuel (ul, dl) et l’insertion d’autre type de bloc. « Y a de la joie » comme dirait l’autre.

Programme de la suite

Ça n’a toujours pas changé :

– Poursuivre l’éditeur
– Finir le design des menus
– Définir les contenus secondaires (bordures, arianes, …)
– Installer le site mère
– Installer x nouveaux Buzz

—
t+=12h30=126h30;

Aujourd’hui ça été la chasse aux sorcières d’événements système. Dur à tracer et à court-circuiter. Au final je les ai brulé. Et maintenant les petits événement obéissent au doigt et à l’œil.

Vous saurez dès à présent (JQuery) que « event.stopPropagation(); » lors d’un ‘mouseup’ est un ami précieux !

S’en suit la suite du programme interminable, j’ai nommé : l’éditeur. On en est à envoyer les données pour insérer un nouveau bloc.

On imagine une insertion mais on oublie vite la quantité de calculs nécessaires à cette élaboration.

Programme de la suite

Ça n’a pas changé :

– Poursuivre l’éditeur
– Finir le design des menus
– Définir les contenus secondaires (bordures, arianes, …)
– Installer le site mère
– Installer x nouveaux Buzz

—
t+=5h=114h;

Au vu des cas différents d’utilisation du système, des besoins de chaque cas et des conséquences occasionnées, j’ai dû trancher dans les décisions.

Ainsi l’édition se fera toujours via le Buzz via son sous-domaine beabuzz.

Ainsi le SSO n’est plus nécessaire néanmoins la possibilité d’avoir un seul compte pour tous les buzz reste inchangée.

Côté édition je progresse, il faut dire que révolutionner le principe n’est pas chose aisée et le tâtonnement avec essais/erreurs n’est pas chose aisée.

De plus la variation des accès rajoute des difficultés supplémentaires.

J’ai revu le CSS du GUI quasi intégralement, il est simplifié et plus discret. Côté mécanique là aussi ça évolue, mais il reste encore pas mal de travail côté user-friendly.

Du côté de ce qui fonctionne, on peut demander à insérer du contenu avant ou après un bloc ou le supprimer.

Le système continue également d’évoluer en se flexibilisant toujours d’avantage. Le système d’édition a des besoins différents par rapport au flux dit ‘standard’.

Il va vraiment falloir penser à écrire une documentation avant la fin et schématiser plus sérieusement l’engin.

Programme de la suite

– Poursuivre l’éditeur
– Finir le design des menus
– Définir les contenus secondaires (bordures, arianes, …)
– Installer le site mère
– Installer x nouveaux Buzz

—
t+=14h30=109h;

Nous utilisions une solution ‘maison’ pour le partage des sessions entre les serveurs.

Aujourd’hui, en travaillant sur l’installation de l’éditeur, un ‘bug’ est survenu. Une erreur survenant après le code, je n’avais jamais vu ça. En fait il s’agissait d’une manipulation simultanée d’une session à 2 endroits. Évidemment ça ne va pas, il n’y a pas de ‘lock’ dans le système actuel.

Je remercie d’ailleurs Patrick A. pour ses connaissances de la mécanique interne de PHP qui m’a permis de corriger partiellement le système de session ‘maison’.

Mais cela n’est pas suffisant, le problème reste entier, juste la conséquence était maitrisée. Il faudrait implémenter un système de lock avec le document de session. De plus on m’a fait remarqué la lourdeur/lenteur des opérations avec ce système ‘maison’.

Enfin soit, l’expérience fonctionne mais ne convient pas à Be a Buzz.

C’est là que je repense à NFS pour y mettre en mode natif les sessions.

2 lignes de codes et 2 fichier de conf après c’était modifié et fonctionnel. J’espère pour un mieux et l’erreur de lock en moins.

Je suis certains que ce foutu système de session m’en fera encore voir à l’avenir car il peut encore être amélioré en terme de vitesse et de place occupée en un point central critique.

La base de l’éditeur, qui était le point de test et d’échec, va enfin pouvoir continuer sereinement. Je pense avoir correctement défini le principe.

Programme de la suite

– continuer l’éditeur
– Implémenter la connexion globale (Single Sign On)
– Fixer le design des menus
– Définir les contenus secondaires (bordures, arianes, …)
– Installer le site mère
– Installer 3 nouveaux Buzz

—
t+=8h=94h30;

Comme je l’expliquais hier, nous avons un soucis de communication. J’explore une hypothèse ou un module central répondrait à la demande, il serait disponible pour chaque Buzz évitant ainsi le trou de sécurité des autres solutions listées.

L’éditeur va pour ainsi s’installer dans le Buzz connecté selon les accès reçus, proposer l’interface et en charger d’autre tout en passant par le flux principal.

Là où ça se corrompt c’est qu’il ne s’agit pas d’une page mais d’un module dynamique, il n’est donc pas ‘pagé’, le système ne traite que des pages, du moins via requêtes traditionnelles. Cette requête sera standard mais annoncera ça différence pour qu’à certains endroits bloquant du processus elle puisse passer outre certaines vérifications. Ceci évidemment sans remettre en cause la sécurité.

On pourrait dire qu’il ne s’agit pas vraiment de corruption mais de négociation afin d’arriver à un résultat : un éditeur centralisé et disponible malgré les différents domaines pouvant communiquer en retour au central pour enregistrer les modifications.

Programme de la suite

– continuer l’éditeur
– Implémenter la connexion globale (Single Sign On) – y a de l’idée, mais c’est compliqué
– Fixer le design des menus
– Définir les contenus secondaires (bordures, arianes, …)
– Installer le site mère
– Installer 3 nouveaux Buzz

—
t+=2h=86h30;