Apicurio-studio: Éditeur : prend en charge allOf (héritage de type de données)

@EricWittmann ayant passé les deux derniers jours dans l'outil, c'est probablement le plus gros écart m'empêchant d'utiliser l'outil avec les clients

D'accord. En l'ajoutant à la liste !

une autre réflexion à ce sujet? Je commence à lire pour démarrer certains projets et j'aimerais utiliser apicruio mais ce problème est un vrai bloqueur

J'ai eu quelques réflexions dans ce domaine mais je n'ai pas eu l'occasion de vraiment travailler dessus. Le backlog de fonctionnalités est assez étendu, y compris une rénovation relativement généralisée de l'UX.

Avez-vous une idée de ce à quoi pourrait ressembler une interface utilisateur prenant en charge allOf (et vraisemblablement oneOf et anyOf) ?

allOf doit me montrer que la définition foo étend la barre de définition et de préférence une énumération des champs qui font partie de la barre. la vue de foo doit créer un lien hypertexte vers la barre. J'imagine une sorte d'écran partagé ici, mais la conception de l'interface utilisateur n'est pas ma force.

oneOf et anyOf sont des cas d'utilisation différents d'un point de vue UX. Dans ces scénarios, je dois simplement énumérer les définitions qui pourraient être utilisées lors de l'attribution d'une variable, mais je n'ai pas besoin de voir les détails des définitions comme c'est nécessaire dans allOf. J'ai juste besoin de connaître la liste des noms de définition.

Je vais soulever le problème avec l'UX pour voir si nous pouvons trouver quelque chose. Malheureusement, ce n'est probablement pas l'élément le plus élevé de la liste des choses à faire, mais je ferai de mon mieux. :)

Compris, je veux juste que vous ayez le contexte de ce qui est nécessaire pour que nous utilisions cette chose dans le laboratoire. C'est le gros problème en ce moment - je peux contourner la plupart des autres choses. Mais je dois être capable de faire de l'héritage dans un projet du monde réel.

Absolument compris. :) Je vais pousser cette exigence autant que possible - j'aimerais certainement qu'Apicurio soit aussi utile que possible dans des projets du monde réel.

Si vous avez d'autres problèmes que vous n'avez pas encore mentionnés et qui peuvent être améliorés, faites-le moi savoir également. (Remarque : nous travaillons à la conception d'une fonctionnalité CRUD, qui facilitera grandement l'ajout rapide d'opérations standard pour une « ressource »)

Bonjour, des nouvelles à ce sujet ? C'est dommage qu'un si bon outil ne puisse pas gérer l'héritage...

Malheureusement rien encore, mais pas par manque de volonté de soutenir l'héritage. Juste un problème de priorisation, vraiment.

Ce qui aiderait beaucoup, si quelqu'un a des compétences en conception UX, c'est une maquette de la façon dont cela fonctionnerait. @sherl0cks a déjà fourni quelques idées, mais il serait beaucoup plus facile de mettre en œuvre quelque chose ici avec un design UX. OU si vous avez un outil qui fait quelque chose de similaire d'une manière que vous aimez, n'hésitez pas à le signaler !

Je me rends compte que cela peut être beaucoup demander. :)

Quoi qu'il en soit, cela se fera, je ne sais pas encore trop quand.

Hey,

si la partie UX est toujours un bloqueur - pourquoi ne pas réutiliser le style d'onglet existant comme https://imagebin.ca/v/4mkbz35931av

Alternative - créez un type de données "composite" (à côté d'un tableau, d'une chaîne, d'un flottant, ...), une fois sélectionné - affichez le même formulaire (où vous pouvez ajouter différents types) avec un peu de remplissage à gauche.

L'héritage ps est une fonctionnalité de documentation d'OpenApi qui tue car elle permet d'économiser beaucoup de copier-coller !

Ce n'est pas une mauvaise conception ! Merci pour la contribution. J'espère que vous êtes d'accord avec cela, mais j'ai pensé qu'il serait utile d'insérer l'image pour faciliter les choses (pas besoin de cliquer sur imagebin):

Non, j'attendrai que cela soit publié, puis je porterai plainte pour violation du droit d'auteur ! :RÉ

ps à part ça - vous avez construit un excellent outil ! Félicitations!

Haha ! ??

En espérant que cette fonctionnalité soit implémentée !

J'y travaille maintenant (enfin). :)

Je sais que cela a pris beaucoup de temps, mais une implémentation initiale du support de base allOf, oneOf et anyOf (évidemment pour les documents OpenAPI 2.0, ce n'est que "allOf").

Ceci est juste une implémentation bêta du support. J'aimerais avoir des retours dessus. Je pense qu'il y a un tas d'améliorations qui peuvent être apportées, mais je m'intéresse d'abord à ce que les autres pensent.

Je vais faire une version aujourd'hui afin que tout le monde puisse tester les fonctionnalités en utilisant la version Try Now (cloud) d'Apicurio Studio.

Corrigé par : https://github.com/Apicurio/apicurio-studio/pull/1022

Il convient de noter que les modifications incluent également des améliorations des types simples réutilisables. J'espère que c'est aussi quelque chose d'utile pour certains utilisateurs.

Malheureusement plus longtemps dans un rôle où j'utilise apicurio, mais ça sonne bien @EricWittmann !