Brols de Killan

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;

C’est ainsi, rien n’est simple. On a un flux, complexe vu de l’extérieure je vous l’accorde, mais quand on s’en approche et qu’on apprend à le connaître… non en fait il reste complexe mais au moins on a appris à le connaître.

Il faut dire que le sujet ‘cross domain’ est un vrai calvaire. Tant point de vue sécurité que les aspects à considérer. Néanmoins, après moult recherches, essais et diverses tentatives une solution acceptable apparait, une fois testée, peut-être, qu’elle sera plus qu’acceptable.

Côté designs, ça avance, les minibab (login, err) sont quasiment fonctionnel.

Point de vue gestion du flux et informations, certaines améliorations ont été mise en place pour augmenter la flexibilité et l’usage.

Programme de la suite

– continuer l’éditeur
– Implémenter la connexion globale (Single Sign On) – y a de l’idée
– Fixer le design des menus
– Définir les contenus secondaires (bordures, arianes, …)

—
t+=6h=84h30;

Suite logique de hier, je me suis attaqué au menu de la page de connexion qui me sert de test en ce moment.

Le principe fonctionne et doit être encore étoffé pour des designs plus complexes.

Toujours dans l’idée de finir ce qui est commencé, le système d’authentification fonctionne et a permis de déceler une erreur glissée dans le système de session.

Le système de contenu structuré continue de faire ses preuves, une vrai belle trouvaille.

Le système de centralisation des erreurs et de guide a été amélioré. Le sous-système interne de gestion d’erreurs propre au système de la V5 a été remplacé par une centralisation dans le module spécifique.

Programme de la suite

– Fixer le design des menus
– Définir les contenus secondaires (bordures, arianes, …)
– Implémenter la connexion globale (Single Sign On)
– Débuter l’éditeur

—
t+=4h30=78h30;

Une bonne journée, le flux de génération de page a été complété. Certes il reste des détails, du développement et des affinages à faire mais le principe des étapes est complet.

Tout a été adapté pour cette version et les tests sont parfaits.

Programme de la suite

– Finir err et login côté dynamisme
– Implémenter la notion de menu et penser la manière de les styler.

—
t+=3h=74h; (?)