Utiliser les calques avec Draw.io

Un outil super cool pour faire des diagrammes est draw.io. Il permet de faire aussi bien des diagrammes techniques, de dev que du plan ou des schémas de bricolage. Y’en a d’autres bien sur, comme cacoo, mais l’avantage de draw.io, c’est qu’il y a une version en ligne ou en local sur notre machine.

Mais pour le besoin d’un projet de bricolage perso, j’avais besoin de séparer mon diagramme en calque, pour ne pas surcharger le schéma et pouvoir organiser mon travail, ceux qui utilisent Gimp ou ToShop savent de quoi je parle.

Les calques

Je ne vais pas refaire un topo l’a dessus, mais comme indiqué avant, c’est fort pratique. Mais dans Draw.io c’est bête, mais c’est à moitié caché. J’ai cherché dans Modifier, Vue, Organiser, mais que dalle, étrange

La fonction de calque est présente sur la photo, seras-tu la retrouver ?

En faite, il faut cliquer là-dessus :

Puis sur « couche »

Ce qui va faire apparaitre la fenêtre de gestion des calques (Layer en anglais et Couches en draw.io 😂), Alors je vais me répéter ce que je dis toujours à mes élèves, ne jamais installer un logiciel en français 😩

Allez bon dev et Banzaï

SOS : Doctrine migration ne répond plus

Bon sous ce titre un peu rigolo, il y a un vrai problème que je trouve assez frustrant et surtout bloquant. En effet une fois que vous avez mis à jour vos package, plus rien ne marche et la console vous envoie un message d’insulte pas piqué des hannetons (et en rouge en plus, le salopiaud):

Unrecognized options "dir_name, namespace" under 
"doctrine_migrations". Available options are "all_or_nothing", 
"check_database_platform", "connection", "custom_template", "em", 
"factories", "migrations", "migrations_paths", "organize_migrations", 
"services", "storage".

Normalement, grâce à composer, on ne dois pas avoir de problème pour l’ajout et surtout la maintenance des packages, d’autant plus avec Symfony. Sauf que dernièrement avec la dernière mise à jour, Symfony passe de la version 5.0 à la 5.1 et surtout DoctrineMigrations passe de la 2.2 à la 3.0 et là, c’est le drame…

J’imagine que c’est un problème de changement de version qui ne doit intervenir que pour les projets existants, mais c’est fort facheux de perdre du temps bêtement comme ça. J’ai trouvé le coupable, (et qu’on lui traaannchee la têeeeeete, euh hem, je m’égare). Bon, c’est le fichier qui va contenir la configuration de doctrine migration, à savoir ./config/packages/doctrine_migration.yaml
En gros dans votre version, vous devez avoir un truc du genre:

doctrine_migrations:
    dir_name: '%kernel.project_dir%/src/Migrations'
    namespace: DoctrineMigrations

Et c’est bien ce que nous dis le message d’erreur, en gros il se prend direct dir_name comme clé, et il a rien compris, ce qu’il attend maintenant, c’est ça:

doctrine_migrations:
    migrations_paths:
        'DoctrineMigrations': '%kernel.project_dir%/src/Migrations'

En théorie, si vous relancer un composer update ou n’importe quelles autres commandes, ça doit passer, par contre si vous voulez faire une migration, et Bim un nouveau message d’erreur:

The metadata storage is not up to date, please run sync-metadata-storage command to fix the issue

Il semblerait que ça viennent toujours de la version 3.0 de DoctrineMigration, qui as aussi changé le format des migrations ainsi que le nom de la table dans la BDD. Ok pas de problème, je lance la commande indiqué et là c’est super rigolo:

php bin/console doctrine:migrations:sync-metadata-storage

Et bah il me raffiche la même erreur, donc en faite, c’est un souci au niveau du serveur, il faut lui indiquer la bonne version du serveur de BDD à utiliser. J’avais laissé le truc de base dans le .env, mais en fait j’utilise Mariadb. Je suis passé à ça : mariadb-10.3.22, et maintenant la commande fonctionne.

En espérant que cela vous dépanne. Allez bon dev et Banzaï

sources:
  • https://github.com/symfony/symfony/issues/37360
  • https://jmsche.fr/fr/blog/mise-a-jour-de-doctrine-migrations-de-2-x-a-3-0


Choisir la version de PHP pour un projet Symfony

Bonjour, alors mon problème du jour est que quand je veux déployer sur un hébergeur mutualisé, je n’ai parfois pas trop le choix de la version de PHP qui va tourner. Par exemple sur mon hébergement de base chez OVH, bah c’est la V. 7.3.18 MAX, or mon site symfony développé sur ma machine avec la dernière version d’Ubuntu qui est sur la version 7.4 de PHP, va se baser sur celle-ci. Je vais donc avoir un joli message comme quoi mon composer.lock ne correspond à la version du serveur.

Pour corriger ça, il suffit d’indiquer dans notre fichier composer.json la version de PHP que nous voulons utiliser.

Au niveau de la clé  » config  » nous allons ajouter la version à utiliser:

« config »: { « platform »: { « php »: « 7.3.18 » },

Une fois fait, il ne reste qu’a supprimer le dossier vendor et de reancer la commande:

 composer install

Gérer les relations ManyToMany dans Symfony

Dans Symfony, ce qui est génial c’est les commandes de génération de Code. Entre le Make:Entity et le Make Crud, on gagne un temps fou, mais il reste une certaine petite chose qui peuvent vous faire perdre du temps si vous débutez.

Et l’une d’elles qui m’as bien pris la tête alors que c’est tout bête, c’est la gestion des relations ManyToMany dans les formulaires.

Pour rappel, un ManyToMany, c’est une relation qui peut avoir plusieurs références à des entités. Comme des tags par exemple, je peux avoir un tag techno qui peut être lié à plusieurs articles, mais un article peut avoir plusieurs tags.

Dans le formBuilder, il faut ajouter sur notre champs M2M, le type de champs, donc EntityType , et la classe cible. 

 ->add('category', EntityType::class, [
                'class' => Category::class               
            ])

Et surtout bien penser à ajouter une fonction __toString sur votre entity, sinon Symfony ne saura pas quoi afficher.


    public function __toString()
    {
        return $this->name;
    }

Faire un effet post-it sur une DIV

HTML

Survole moi maybe …

CSS
.effect {
position: relative;
background-color: #fae9a4;
width: 300px;
height: 350px
}

.effect:before,
.effect:after {
z-index: -1;
position: absolute;
content: «  »;
bottom: 25px;
left: 10px;
width: 50%;
top: 80%;
max-width: 300px;
background: #777;
box-shadow: 0 35px 20px #777;
transform: rotate(-8deg);
}

.effect:after {
transform: rotate(8deg);
right: 10px;
left: auto;
}

Installation de MySQL sur Ubuntu

Tout d'abord bien lancer la commande 

apt-get update

pour récuperer les dernières mise à jour.

Après un traitement plus ou moins long, normalement il vous demande de creer un utilisateur pour la gestion des base de données. Si ce n'est pas le cas, comme pour moi, il suffit de taper :

sudo mysql_secure_installation

On va vous demander le mot de passe admin, si l'ont doit supprimer les acces anonyme.

Générer les classes et les accesseurs avec Symfony depuis une BDD

Il est possible de générer toutes les classes et les entités depuis une base de données existante.

Cette commande génére l'entité sous forme de classe PHP: 

php bin/console doctrine:mapping:import 'App\Entity' annotation --path=src/Entity

Si vous préferez le yml ou le xml à la place des annotations, il suffit de replacer annotation dans la commande.

 

Pour générer les accesseurs, il suffit de taper: 

php bin/console make:entity --regenerate App

Il reste quelque petit trucs à ajouter à la main, mais ça supprime déjà pas mal de travail répétitif et sans intérêt.