Mot-clé - namespace

Fil des billets - Fil des commentaires

22/05/2022

getProperties

Ca y est cette fois, j'ai tout cassé. Toujours à fond sur la branche namespace de dotclear, je continue de me lâcher, pas moins de 70 fichiers modifié juste pour un changement qui n'en est pas un. J'aime

La solution retenu pour supprimer ces ArrayObject est de passer une petite classe à toutes les méthodes faisant des requêtes complexes sur la base. L'avantage est de retourner un type de propriété connu, propriété qui sera nettoyé avant requête, ça évite les plantages mais pas les erreurs car un type ne correspondant pas sera tout simplement ignoré et donc on aura un résultat pas forcément attendu. L'autre avantage et que les filtres de liste étaient prêt pour ça ! (Promis je l'avais pas fait exprès) L'inconvénient est que ça rajoute du code, pour le coup je ne suis pas encore satisfait de cette solution. M'enfin c'est comme souvent, nouvelle idée, rajout de code, optimisation, réduction de code. J'arrive à stabiliser à peu prêt la légèreté (lourdeur?) de l'ensemble.

PS: J'en ai profité pour commencer à uniformiser l'aspect de ces méthodes (getPosts, getUsers, getComments, getLog, etc...) Elles ont désormais toutes la même signature et ça, ça me plait !

12/05/2022

Dotclear Nx - Késako

Mais pourquoi donc réinventé la roue ! dotclear fonctionne très bien aujourd'hui, il est bien écrit, rapide et est solide.

Tout simplement parce que j'aime m'amuser, j'aime tout cassé. Et puis les dernières versions de PHP apportent pas mal de changements à la fois sympa et … incompatibles. Avec le temps dotclear va devenir de plus en plus difficile à maintenir et le code ne sera plus du tout lisible par les petits jeunes qui arrivent. Et puis se demander à quoi pourrait ressembler le futur si on fait sauter les barrières de rétro compatibilité, ça peut-être intéressant de tester de nouvelles pistes, quitte à tout casser. Bien entendu, je baigne dans l'environnement dotclear depuis des années donc je garde en tête la vision de se moteur de blogs et j'essaie d'y rester attacher. Je remercie ici au passage le grand patron qui est toujours à l'écoute et sait me conseiller quand j'hésite ou je patauge.

Pourquoi dotclear Nx ? Parce que je suis fainéant. Le N pour namespace qui j'écris toujours en dyslexie, et le X parce que ce n'est (et sera peut-être) pas une version de dotclear !

C'est quoi le but ?

Bref, techniquement parlant, quelles sont les grandes lignes, les principales idées qui cassent tout de cette branche de dotclear:
  • Tout passer en espace de noms et rendre compatible avec des outils moderne tel que composer (même si ça ne sert pas à grand chose avec dotclear qui n'a besoin de personne pour tourner !),
  • Améliorer la gestion des plugins et thèmes avec du multi répertoire, par plateforme, par config, par blog ou que sais je,
  • Améliorer la gestion des dates (encore un truc qui casse tout…),
  • Virer tout ce qu'il y a de l'ancien monde PHP: globales, constantes, méthodes magiques, etc., fourre tout. (oui j'y vais un peu fort là),
  • Repérer et simplifier le typage des méthodes,
  • Fourniture des toutes les ressources à travers un gestionnaire (permettant aux dites ressources de se cacher n'importe ou

Y a quoi dedans ?

Petit tour des nouveautés de Dotclear Nx par rapport à dotclear 2
  • Requière PHP 8.1 (va encore monté en version avec le temps)
  • Arborescence en espace de nom
  • Compatible composer, PSR4, PSR12
  • Inclue la librairies clearbricks
  • Fichier de configuration plus complet. (Plus de contante de configuration)
  • Classe Core en singleton, disponible n'importe ou dans le code.
  • Gestion par Process (Admin, Public, Install, etc)
  • Gestion similaire des plugins et theme en Modules (Plugin, Theme), permettant le multi répertoire plus poussé et une écriture de code simplifiée.
  • Gestion standardisé des dates, UTC dans la base et dans la manipulation des dates, fuseaux horaire du blog coté public, fuseaux horaire de l'utilisateur coté admin.

C'est quoi qui est cassé ?

Petit tour de tout ce qui casse la compatibilité directe entre dotclear 2 et Dotclear Nx.
  • Toutes les fonctions, tous les fichiers, toutes les classes sont retravaillées en classe avec une classe par fichier,
  • L'arborescence des répertoires est complètement revu avec un structuration plutôt axée sur le type, la portée, le processus lié à la classe utilisée,
  • La librairie clearbricks a été intégré a dotclear et seul les méthodes utilisées dans dotclear sont restées,
  • La cœur de dotclear souvent nommée $core et fréquemment appelée en globale n'existe plus, il est remplacée par un instance singleton nommée App:core(),
  • Les pages public, admin, install, etc sont devenue des Processus qui cloisonnent ce qui est accessible,
  • Tous les appelles à des globales sont proscrits, le fait que tout passe par des classes ne nécessite plus ce genre d'utilisation,
  • Toutes les constantes sont proscrites, des classes de configuration avec interdiction de réécriture sont disponibles pour ce genre d'utilisation,
  • Les méthodes magiques __get(), _set(), __call() sont proscrites (autant que possible),
  • Une grande majorité des classes statiques sont devenues dynamiques (exceptions faites de sclasses d'outils appelées Helper),
  • La Classe core a été divisé par type et est devenue Core, un conteneur d'instance de sous classes (User, Blog, etc...),
  • La gestions de plugins et des thèmes est regroupé sous une même bannière nommé Modules de type Plugin ou Theme,
  • Toute la gestion de date passe par une unique classe, toutes les dates en base de données sont exprimées en UTC,
Au fil du temps, je ferais des articles pour expliquer certaines choses pour ceux qui veulent comprendre ou même tester cette branche. Même si cette version ne sort jamais elle sera, je l'espère, une mine d'idée pour le futur.

PS: 

J'oublie le principale ! Si vous voulez voir le code de cette branche chez moi:

13/02/2022

Pas de bras, pas de bras

Je profite de la sortie de Dotclear 2.21 pour faire le point sur le défi que je m'étais lancé il y a maintenant 2 mois.

Depuis fin décembre, je travaille sur une branche Namespace de Dotclear et autant le dire tout de suite, il n'y a plus aucune chance que je réussisse à rendre ce code compatible avec la branche master (les versions actuelles).

Et je commençais même à baisser les bras à cause de la lenteur extrême de mon code, et aidé par le passage du COVID qui m'a ruiné une semaine… Jusqu'à ce que j'en trouve la raison et revienne à une vitesse d'exécution un peu plus normale (autant le code que moi!). Bref, le mal de crâne passant je vais bientôt pouvoir me replonger dedans et continuer à tout casser car même si le fait est que ce code est incompatible avec l'existant, il y a pleins de bonnes choses dedans. Pour parler technique, voila quelques exemple :

  • Gestion de l'arborescence façon PSR-4 et donc normalement composer compliant,
  • Plus de clearbricks, qui est engloutie par Dotclear,
  • Plus d'appelle à des global sortie du chapeau, tout passe par l'application (super nom fourre tout),
  • Plus de constante de configuration, idem tout est dans l'appli,
  • Le truc qu'on appelle application est accessible n'importe ou n'importe quand dans le code,
  • Refonte totale façon modules des plugins et thèmes qui deviennent des types de modules,
  • Multi répertoire de thèmes avec possibilité de répertoire par blog,
  • Pour ça, passage de toutes les requetes (page,img,css,js,etc) par un gestionnaire d'URL (lourd mais souple)
  • Et j'en oublie pleins… 
Donc même si cette branche ne sort jamais, je m'amuse bien et il y a pleins de bonnes idées dedans, ça servira toujours.

Coté planning, je m'était donné 1 an pour rendre un verdict, j'en suis à deux mois, see you later.

19/12/2021

Jme lance, Lucette

Comme d'habitude, il suffit d'une idée qui me passe par la tête pour me lancer à corps perdu dans une aventure bien trop périlleuse pour moi.

Il y a quelques temps, j'ai commencé à regarder le fonctionnement des espaces de noms dans PHP, avec 10 ans de retard et l'impasse que j'avais fait sur ce système de gestion de classe, l'affaire n'était pas gagnée. Dès le premier aspect ça ma titillé et j'ai, comme toujours, mis mon cerveau en ébullition: Les espaces de noms de PHP permettent une gestion ultra simple de l'auto-chargement des classes depuis leurs différents dossiers. Il n'en fallait pas plus pour que j'attaque à recoder mon moteur de blog préféré en suivant ce principe. (En vrai je me suis fait la main sur des plugins qui tournent chez moi avec ces fameux namespaces) Et voila, je n'ai pas réfléchie, ça engendre des milliers de problèmes et d'incompatibilités avec le code actuel et je suis donc en train d'adapter et de bricoler pour que ça passe. Et comme il y a un moment ou évidement ça ne passe plus, je recommence en modifiant en conséquence. Je suis borné, j'ai déjà recommencé 3 ou 4 fois.

Il serait bon que pour une fois, vu que ça à l'air de me plaire, je prenne le problème dans son ensemble et que je pose les bases d'une réécriture propre. Je sais faire ça moi ? 

20211218-01.jpg, déc. 2021
Ambre et Oriane - La Panicière - 12/2021

 

Pour la petite histoire, je suis partie sur du 100% classe, plus de fichiers avec des bouts de code, plus de fichier avec 5 ou 6 classes dedans. Cette structure m'oblige donc à revoir certains aspects et rendent le code absolument incompatible (pour le moment) avec l'existant. Par exemple, les pages de la partie administration seront servies depuis un seul point d'entrée et non plus une page/fichier par lieu. Les plugins ne seront plus non plus géré comme aujourd'hui par fichier (_define.php, _admin.php, etc) mais pas classe. Tous les passage pirouettes du core de Dotclear à des méthodes statiques à travers des globales seront à proscrire. (J'ai même envie de passer en dynamique pas mal de classes) J'ai donc pas mal de soucis en perspective. Mais c'est ce qui fait la beauté du jeu. Et puis Dotclear est assez solide aujourd'hui pour que ce ne soit pas une nécessité avant longtemps. Ouf. Ah, et au passage, clearbricks serait engloutie par Dotclear. Voila.

Haut de page