En quête de versatilité

Les tableurs sont-ils la solution à tout ?

a marqué ce sujet comme résolu.

:) SQL, sors de ce corps ! C’est vrai que je sens bien le SQL en toi, mais c’est plutôt bien, c’est synonyme de rigueur. Si ça ne se transforme pas en rigidité, c’est une bonne chose.

Pour la structure/ossature de notre objet model, je pensais créer un objet ossature avec comme propriétés les champs et en valeur le type des champs.

Oui, comme le « Mode création » d’Access si je comprends bien.

Quel(s) langage(s) de programmation parles-tu ? On pourrait peut-être mieux communiquer via des snippets… Personnellement, je comprends principalement le Javascript, mais je peux sans doute m’adapter à d’autres choses (pas trop exotique hein).

Aussi, une autre façon de « concevoir » notre outil pourrait être de prendre la discussion dans l’autre sens : on commence par discuter de l’apparence qu’on voudrait obtenir, pour venir petit à petit vers les mécanismes sous-jacents.

Edit : tu veux vraiment faire des classes, ou il y a moyen de bosser avec des protos ?

versatile-ui
+0 -0

Oui, comme le « Mode création » d’Access si je comprends bien.

C’est bien ça.

Quel(s) langage(s) de programmation parles-tu ? On pourrait peut-être mieux communiquer via des snippets… Personnellement, je comprends principalement le Javascript, mais je peux sans doute m’adapter à d’autres choses (pas trop exotique hein).

Le JavaScript me va très bien mais je n’ai jamais utilisé mangoDB (ou autre NoSQL)en JavaScript.

Aussi, une autre façon de « concevoir » notre outil pourrait être de prendre la discussion dans l’autre sens : on commence par discuter de l’apparence qu’on voudrait obtenir, pour venir petit à petit vers les mécanismes sous-jacents.

Ok, j’ai détaillé car tu m’as dis "concrètement". :p

Edit : tu veux vraiment faire des classes, ou il y a moyen de bosser avec des protos ?

Sème

Je dis class mais ce n’est pas au sens strict tout autre alternative JS me va bien. Quand tu dis prototype c’est comme ça ? Ou Prototype.js ?

Non non, c’est bien "prototype" comme ça, je ne pensais pas à Prototype.js :)

Bon j’ai repris mon petit dessin en le remplissant pour faire un exemple :

versatile-ui2

Tout en haut, c’est l’identifiant de l’objet, pas grand intérêt du côté utilisateur pour l’instant.

Juste en dessous, en orange, c’est "l’étiquette" de l’objet. C’est un peu comme un titre, mais c’est aussi ce qui apparaît dans les zones "valeurs" en dessous.

En dessous de l’étiquette, on a une série de propriétés non héritées, propres à l’objet. On a un rappel visuel de leur caractère "non hérité", parce qu’il n’y a aucune barre bleue au-dessus. Ici, il n’y en a qu’une : le commentaire.

En dessous, on a quatre prototypes de cet objet. A chaque fois, ça commence par une barre bleue, affichant l’étiquette du prototype. Sous la barre bleue, la série de couples clef/valeur hérités du prototype en question. Colonne de gauche, les clefs bien sûr, et colonne de droite, les zones "valeurs" (les valeurs sont des objets aussi), soit n’affichant que les étiquettes des valeurs comme ici, soit pourquoi pas en insérant une représentation complète de l’objet valeur.

Je n’ai jamais touché à mangoDB, mais je me souviens que couchDB est capable de générer et servir lui-même les pages web basées sur les données demandées. Est-ce une solution ? je ne sais pas.

Comment tu vois l’interface toi ?

Edit : plus j’y réfléchis, plus je me dis que ça ressemble à un INI file ce truc. Donc l’interface pourrait être une simple textarea flanquée d’une série de liens-boutons pour manipuler les données. Je suis barjo.

+0 -0

Je t’ai lu, j’ai fais autres choses, j’ai réfléchi, puis j’ai encore fait autres choses. Au final je ne réponds que maintenant. :’)

versatile-ui2

Ca ressemble à la même structure des fichiers .ini en VB.

On part donc sur un seul niveau ? On n’accepte donc pas plusieurs niveaux ?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
humain = {
   age: 48,
   sante: {
      malade: false,
      encorelongtempsavivre: true
   }
   membres: {
      bras: {
         tatouage: true
      }
   }

};

Comment tu vois l’interface toi ?

Sème

Similaire à ce qui existe/Excel/Access/Phpmyadmin, un thème neutre. On peut faire un tableau qui affiche en colonne les entrées (selon les principales propriétés) puis à la fin mettre un "+" qui découle vers ton versatile-ui2 ?

Ou afficher ton menu dans un volet comme dans visual studio ou autre logiciel similaire, comme sur l’image.

Je l’ai fais très rapidement

Oh si, on accepte plusieurs niveaux ! C’est juste que, au sens stricte, un tableau associatif c’est des strings qui renvoient à des refs d’autres objets.

Regarde Cascade framework par exemple, à la section "collapsing". Si la valeur est simple, en afficher l’étiquette suffit. Par contre pour une valeur composée, l’utilisateur peut "déplier" la valeur, et se retrouver avec une interface dans l’interface. Qu’est-ce que tu en penses ?

Tu peux préciser l’idée de tableau stp ?

Edit : Pour les formules style Excel dont tu parlais, j’avais fait une syntaxe, BLACK:TIGER:, qui pourrait peut-être convenir ?

+0 -0

Tableau dans le sens que les entrées sont triés par ligne dans un premier temps pour permettre une vue globale. Pour faire un rapide constat de ce qu’il y a.

Après on est libre de faire un affichage donné par donné.

Edit : Pour les formules style Excel dont tu parlais, j’avais fait une syntaxe, BLACK:TIGER:, qui pourrait peut-être convenir ?

Il me semble qu’il suffit de faire un arbre binaire : https://openclassrooms.com/courses/calcul-d-une-expression-mathematique

+0 -0

Ah j’ai compris pour le tableau : tu es possédé par le SQL !! Chaque colonne correspond à une propriété, et chaque ligne correspond à un objet, c’est bien ça ?

Pourquoi pas, c’est une bonne idée !

Du coup ça voudrait dire qu’on a énormément de cases vides dans cette grille, puisque chaque objet a potentiellement un jeu de propriétés différent. Donc ce que je propose, c’est que quand on sélectionne une ligne de la grille, seules les colonnes pertinentes pour cet objet apparaissent, et les autres sont masquées. Cela permet de comparer ce qui est comparable. Si on sélectionne plusieurs lignes, toutes les colonnes nécessaires sont affichées. Vu que le nombre de colonnes varierait constamment, on mettrait le panneau "objet" plutôt à gauche de la grille. (Remarque, le panneau aussi risque de changer de taille, alors qu’est-ce qu’on fait ?)

Par rapport aux formules, PEGjs permet de parser assez facilement tout et n’importe quoi, si on décidait d’implémenter ça en JS. Mais j’ai constaté que la syntaxe des fonctions Excel pose souvent problème aux apprenants. Alors je me disais qu’au lieu de

1
=RECHERCHEV(G5;$A$1:$D$50;3;0)

Il pourrait être plus clair d’écrire

1
(recherchev: G5 dans: $A$1:$D$50 colonne: 3 correspondance: exacte)

Il n’y aurait pas de recherchev, ni de coordonnées de cellules dans notre outil bien sûr, c’est juste pour montrer la syntaxe. Mais bon on peut faire autre chose si tu veux. Par contre pour l’arithmétique simple, je suis d’accord : il faut rester dans la notation infix classique, c’est clair.

Hey, c’est moi ou ça commence à avoir de la gueule ? :p

+0 -0

Ah j’ai compris pour le tableau : tu es possédé par le SQL !! Chaque colonne correspond à une propriété, et chaque ligne correspond à un objet, c’est bien ça ?

Pourquoi pas, c’est une bonne idée !

Je ne conçois pas d’avoir aucune vue globale. Je trouve que c’est indispensable.

Du coup ça voudrait dire qu’on a énormément de cases vides dans cette grille, puisque chaque objet a potentiellement un jeu de propriétés différent. Donc ce que je propose, c’est que quand on sélectionne une ligne de la grille, seules les colonnes pertinentes pour cet objet apparaissent, et les autres sont masquées.

Fondamentalement elles ne peuvent pas être aussi différente que ça, il doit avoir obligatoirement une similitude, sinon on essayerait pas de les traiter ensemble. En effet, il faut cacher les propriétés secondaires, des principales.

Mais j’ai constaté que la syntaxe des fonctions Excel pose souvent problème aux apprenants. Alors je me disais qu’au lieu de

1
=RECHERCHEV(G5;$A$1:$D$50;3;0)

Il pourrait être plus clair d’écrire

1
(recherchev: G5 dans: $A$1:$D$50 colonne: 3 correspondance: exacte)

Je pense que c’est un manque de volonté de leur part… Il y a des explications/exemples dans l’aide d’EXCEL (F2) et une GUI expliquant les fonctions et paramètres… Je ne sais pas comment faire mieux.

Je ne pense pas que rendre plus littéral les fonctions facilitent la tâche. Ça entraine surtout à un manque de lisibilité. J’ai l’impression que tu as écris la même chose mais simplement dans un autre format, je ne pense pas que ça soit plus facile l’un ou l’autre.

Fondamentalement elles ne peuvent pas être aussi différente que ça, il doit avoir obligatoirement une similitude, sinon on essayerait pas de les traiter ensemble. En effet, il faut cacher les propriétés secondaires, des principales.

Pour parler "bdd", dis-toi que c’est comme si on travaillait avec tout dans la même table ! Donc il y a des groupes qui se ressemblent, mais on distingue aussi des familles d’objets hétérogènes.

Je pense que c’est un manque de volonté de leur part… Il y a des explications/exemples dans l’aide d’EXCEL (F2) et une GUI expliquant les fonctions et paramètres… Je ne sais pas comment faire mieux.

Attention, je ne travaille pas avec des gamins qui ne pensent qu’à fumer. Je bosse avec des adultes, souvent en reconversion professionnelle, et qui, la plupart du temps, découvrent Excel. Je t’assure qu’ils font vraiment preuve de beaucoup de volonté !

Mais bon, je suis Ok pour une syntaxe à la Excel.

Oui, en général ils commencent par ça, puis petit à petit je les habitue à travailler directement en saisissant la formule, comme tout bon ninja qui se respecte ;)

Edit : Tu sais à quoi ça ressemble aussi ? Du CSS… Ben oui finalement, on retrouve la cascade de propriétés héritées, appliquées à des éléments grâce à des sélecteurs.

Edit : C’est même plus puissant à la limite, le CSS. Imagine : ça permet de rajouter une floppée de propriétés à des entités que tu sélectionnes. Tu vois ce que je veux dire ?

+0 -0

N’hésite pas à reposter un message plutôt qu’éditer comme ça j’ai l’alerte pour la modification. Surtout si c’est une modification 3 heures après. :p

Edit : C’est même plus puissant à la limite, le CSS. Imagine : ça permet de rajouter une floppée de propriétés à des entités que tu sélectionnes. Tu vois ce que je veux dire ?

C’est du json ça ?

Non, ce que je voulais dire, c’est que le CSS te permet d’attribuer des choses depuis l’extérieur. T’es pas obligé de mettre ton style en inline dans les balises html, n’est-ce pas ? Ben on pourrait imaginer la même chose pour les objets.

Mais bon c’était juste une divagation…

Bon je vais essayer d’exprimer clairement la chose, mais juste pour le sport parce que je pense que ça sort du cadre de ce dont on discute ici.

Sur HTML/CSS, tu as ton squelette HTML, et tu attribues à certaines balises des classes, et des identifiants. Les balises ont aussi un tagname, et une place dans le squelette HTML.

Tous ces éléments permettent de sélectionner les balises auxquelles on souhaite appliquer des styles dans le CSS. Maintenant compare un fichier CSS et un fichier classique de définition de classes. Dans le CSS, tu as une malléabilité supérieure : grâce à des sélecteurs, tu peux appliquer des styles en fonction du type de balise, de l’emplacement dans le squelette HTML, de la classe, et de l’identifiant. Un fichier de définition de classe est beaucoup plus rigide : tu définies une classe une seule fois, et tout ce qui la concerne doit se trouver au même endroit.

Donc ce que je me disais, c’est qu’on pourrait utiliser cette force de CSS pour attribuer des choses aux entités qu’on traite dans notre outil. Sauf que voilà : je ne pense pas que ce soit une bonne idée d’aller dans cette direction, parce qu’en termes de maintenabilité, ça risque de compliquer les choses, et de rentre l’outil peut-être trop complexe.

Que penses-tu de Zenkit ? Versatile, simple, peut-être que ça répond à nos besoins. Je vais tester, il y a peut-être des idées à récupérer, au niveau UI.

Edit : Bon, on a vite fait le tour. Zenkit fait ce qu’il annonce, rien de plus. Pour résumer, on peut enregistrer des données, et les lire sous différents formats de présentation : liste, kanban, calendrier… Aucun outil de traitement des données, et surtout aucune notion d’héritage. Sinon c’est propre.

Edit : Je reviens sur ce que j’ai dit, il y a des formules. Bon je suis en train de consulter la doc. C’est du sérieux là, parce qu’à la base je cherche un outil à utiliser en production, faut que ce soit à l’épreuve des balles !

Edit: Je continue mon petit retour d’XP. Il faut assez vite essayer d’importer un CSV avec 300 lignes. Boum, le temps de réaction à la molette de la souris est d’1 seconde. Incroyable.

+0 -0

Oui c’est un framework UI HTML/CSS/JS. Je m’en suis servi pour faire mon IDE de création de supports pédagogiques, sur nwjs justement. Ils ont notamment un ruban qui marche vraiment bien.

Enfin ça ou autre chose.

Hey, ou alors on part old-school avec blessed :soleil: Nan je déconne.

+0 -0

Voici la liste de ce que peut faire DHTMLX. La plupart des composants sont gratuits, à quelques exceptions près (je sais que le TreeGrid est payant, il me semble qu’il y en a un ou deux autres, à vérifier). C’est clean, impersonnel.


Sous le capot, voilà à quoi ça pourrait ressembler. Un store de JSON, simplement. Mais en faisant les choses d’une certaine façon…

Si tu connais les fonctions map/reduce/filter, tu sais qu’on applique ces fonctions à une liste d’éléments soit pour produire une nouvelle liste (map) soit pour les synthétiser en une seule valeur (reduce), soit pour les filtrer.

Maintenant imagine que tu as une bonne grosse liste. Régulièrement, tu as besoin de consulter, disons, la somme des propriétés "fooX" de tous les objets qui ont une propriété "concerné" == true. A chaque fois il faudrait faire un filter pour ne garder que les objets en question, puis un reduce pour faire la somme. Si la liste est grosse, ça prend du temps de refaire l’opération à chaque fois qu’on veut consulter la somme en question.

Mais si on inverse le problème, ça devient beaucoup plus rapide. Au lieu de faire l’opération au moment de consulter la somme, on la fait au moment d’insérer un nouvel objet dans la liste, au moment d’en modifier un, et au moment d’en supprimer un. C’est rapide, puisqu’au lieu de parcourir l’ensemble des objets de la liste, on parcourt juste l’ensemble des "vues" qu’on souhaite maintenir à jour. Les vues peuvent être nombreuses, plusieurs dizaines, mais c’est rien comparé aux dizaines de milliers d’objets qu’on pourrait avoir envie de gérer en liste.

Voilà, selon ce que j’ai cru comprendre, le principe de base du nosql. Si je me trompe, merci de me corriger. Je sais pas si tu connais ces trucs là ou pas, alors dis-moi ce que tu en penses.


Pour l’instant j’identifie 4 types d’interface :

  • En grille, façon tableur

  • En calendrier

  • En kanban

  • En formulaire

5 si on compte les cartes conceptuelles.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte