Nouvelle gem pour construire une interface d'admin rapidement

[Guirec Corbel]

Salut,

J'ai fait une gem permettant de faire une partie d'administration à la
fois facile à faire et très configurable :
https://github.com/gcorbel/smart_management. Je suis intéressé par vos
commentaires. J'espère pouvoir faire avancer cette gem là, faire un site
de démonstration et avancer dans ma démarche une fois que j'aurais
réunis des commentaires.

Merci pour votre aide,
Guirec.

[Julien Grillot]

Salut,

J'y vais en vrac :)

– Quelles différences avec les autres gems d'administration ?

– Est-il possible de résumer l'installation à une ligne de Gemfile, de JS et de CSS ?

– Que faut-il faire pour sécuriser son app' si l'on installe cette gem ?

Merci pour ta contribution,
Julien

> --
> --
> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de
> Google Groups.
> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
> rails...@googlegroups.com
> Pour résilier votre abonnement envoyez un e-mail à l'adresse
> railsfrance...@googlegroups.com
> --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
> Railsfrance.
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> concernant, envoyez un e-mail à l'adresse
> railsfrance...@googlegroups.com.
> Pour plus d'options, visitez le site https://groups.google.com/d/optout .

[Guirec Corbel]

Bonjour,

Comparé à des gems comme ActiveAdmin ou RailsAdmin, j'ai préféré en faire moins et laisser l'utilisateur profiter de la puissance de Rails en faisant en sorte qu'il soit facile de surcharger le comportement par défaut. J'ai longtemps utilisé ActiveAdmin et, je trouve que ça va très bien quand c'est simple mais dès qu'il y a de la complexité ça devient vite plus ardu que de faire ne application Rails à la main.

Je vais simplifier le processus d'installation. J'ai préféré utiliser plusieurs lignes étant donné qu'il est possible que l'application possède déjà ces dépendances. Je vais voir ce que je peux faire.

L'application en elle même n'a pas de sécurité par défaut. Étant donné qu'il s'agit d'une application Rails, il est facilement possible d'ajouter des gems comme devise. Ça laisse toute la souplesse au programmeur d'utiliser ce qu'il préfère.

Merci pour ton commentaire, ce sont des bons points à ajouter dans le README.

Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Guirec Corbel]

En y repensant, ce que j'ai un peu oublié dans mon README est que SmartManagement n'est pas uniquement fait pour faire une partie d'administration mais peut également servir à tout type de gestion et s'insérer facilement dans une application Rails.

[Florian Dutey]

Salut. Desole par avance parce que ca peut paraitre un peu "frontal" comme commentaire mais quel est le but de refaire un énième ActiveAdmin a l'heure des single page application? 

[Guirec Corbel]

Comme je disais hier, je trouve que mon outil est beaucoup plus simple à modifier qu'ActiveAdmin et laisse utiliser la puissance de Rails. Je ne comprend pas tout à fait le lien avec les SPA ? Peux-tu préciser ?

D'après les commentaires que je reçois, les gens sont tout à fait satisfait de ce que fournit ActiveAdmin. Personnellement, je préfères utiliser SmartManagement. Je pense que je vais continuer à le maintenir pour moi et me lancer dans un autre projet open source qui aura peut-être plus de succès. Au moins, je ne vais pas me casser les reins avec un projet qui ne sera probablement pas populaire.

[Florian Dutey]

Precisons precisons:

1) Ton outil est plus simple a modifier qu'active admin probablement parce qu'il n'en est qu'au debut et permet de repondre a un besoin tres simple et tres specifique. Mais reduire un framework a un cas d'utilisation precis est justement l'inverse de ce que fait un framework (regarde la complexite de rails lui meme).

Soit tu gardes un scope tres limite, mais ton outil sera tres limite lui aussi et tu devras probablement toi meme l'abandonner des qu'une appli grandira en complexite, soit tu devras tendre vers ce que fait AA. 

2) Sur la question des SPA, la ou je veux en venir c'est que clairement, l'avenir du web est de ce cote la. Quand tu vois l'evolution avec sproutcore puis backbone puis ember / angular et enfin react, tu ne peux qu'en etre convaincu.

La toute derniere tendance qui se dessine en terme d'architecture est clairement de separer le serveur de data (rails par exemple) en "API privee" et d'utiliser un serveur d'API publique pour exposer ce que l'on souhaite vers l'exterieur, gerer les taches longues et complexes (parfaitement gerees par un serveur en JS puisque asynchrone). Pour faire tres vulgaire, cette tendance remise rails au layer des modele, les "controllers" sont geres par nodejs (asynchrones, plus besoin d'enqueue des traitements longs dans des jobs), la vue par un CDN ou un server webpack (un milliard de fois plus smart que le pipeline de rails).

Bref, la ou je veux en venir, c'est que le serveur rails qui delivre du html, c'est une vision qui commence a dater selon moi et je disais, sans animosite aucune, crois le bien, que c'est peut etre dommage de fournir des efforts pour un pattern qui appartient desormais au passe.

Voila, ca vaut ce que ca vaut, c'est juste mon pauvre avis. :)

[Jean-Hadrien Chabran]

Disons que d'un point de vue de la popularité, si tu joues sur le même terrain que active admin, cela va être difficile de gagner de la traction. L'espace d'admin est souvent un truc avec lequel les devs gagnent des tonnes de temps en utilisant des solutions comme ActiveAdmin et la tienne. Du coup, la question de la pérennité est critique, car c'est typiquement une brique qui va pas trop bouger et pas particulièrement intéressante à coder (en tout cas sur des applis métier classiques). Résultat des courses, prendre le truc archi classique (certes un peu relou de temps en temps) mais dont on est sûr que la core team est là pour les 3 prochaines années, est un choix très commun. 

La mode étant aux SPA, avoir l'admin sous cette forme peut séduire une partie des devs qui chercheraient à avoir un admin un peu plus sexy, d'autant plus qu'on aurait pu imaginer que la brique d'admin soit découpée en deux partie, le client qui au final dépendrait juste d'une api restful et de l'autre côté ton backend par "défaut" pour rails, qui peut être donc remplacé si besoin, y compris par un truc dans un autre langage (hop, à toi le ActiveAdmin qui marche avec Django/Rails/Phoenix/whatever).

Au délà de ces considérations, ActiveAdmin, avec ses défauts bien entendu, est battle-tested, on sait que si on l'envoie dans l'app, on devrait s'en sortir et pas se bouffer (trop) d'edges cases bizarres, car bah avec le parc d'applications qui s'en servent, les devs ont bien du voir passer la majorité des edges cases. Now, quand tu devs toi même le truc, factuellement tu ne peux pas être aussi fiable (face à ces edge cases*), elle peut le devenir, mais il faudra un moment. 

Si la finalité c'était de produire une gem populaire, cela va être tendu. Si c'était de te faire ton propre backend, awesome :] tu as du apprendre plein de trucs en le faisant et now tu as du code que tu connais par coeur pour l'admin de tes apps.  Ton mail initial ne suggérait pas tellement la deuxième option. 

* edges cases : combinaisons obscures de versions/implé de ruby, de rails et autres gems, datastores, cache http, plugins et autres joyeusetés :)

My 2 cents, 

Jean-Hadrien Chabran

[Guirec Corbel]

Florian, pour ton premier point, je ne suis pas d'accord. Je trouve justement que mon outil gagne avec la complexité étant donné qu'elle est très simple et laisse à Rails prendre la place qui lui revient. Pour ton second point, je suis tout à fait d'accord. J'avais d’ailleurs commencé à vouloir faire un outil qui soit juste une api mais qui fournisse également une interface de gestion. Cependant, je me suis un peu casser les dent là dessus et j'ai trouvé ça plus complexe qu'autre chose. Je suis donc venu à une vision plus simple.

Jean-Hadrien, je pense en effet que la partie d'admin n'est souvent pas jugé critique mais, de mon expérience, on se retrouve souvent avec des bogues à résoudre, des éléments qui manques, des lenteurs, etc. On travail avec un Framework puissant, Rails. Pourquoi ne pas profiter au maximum de sa puissance et fait les choses proprement ? Au niveau des edges cases, encore une fois, je profite de Rails. SmartManagement est juste une brique intégré à d'autres briques que l'on utilise dans Rails.

Je comprends bien, ce que vous pensez qui pourrais avoir plus de succès ça serait une api qui puisse être tout aussi facilement faisable et configurable. l'intérêt serait donc de pouvoir porter l'outil sur autre chose que Rails. C'était mon but au départ et je crois qu'il va falloir que j'y repense. Ça ne devrait pas être si compliqué. Je crois que je vais juste avoir des problèmes au niveau du schéma de données. Si des personnes ont des idées, je suis ouvert à toute proposition.

Merci pour vos avis.

[Guirec Corbel]

Dans le fond, la question est de savoir ce qu'est une interface d'administration idéal. Je ne pense pas qu'il faut absolument que ça soit une SPA. Je comprend l'utilité de l'API avec une séparation claire entre la vue et la logique serveur. La difficulté est surtout au niveau de la structure des modèles. C'est assez facile, avec Rails, d'utiliser `Model.columns` et `reflect_on_all_aggregations` pour avoir les informations nécessaire pour construire l'interface d'administration. Si on veut découpler la vue, il faut trouver un moyen de recevoir ces informations. Évidement, il est possible de faire une requête pour donner les informations mais je ne suis pas certain à 100% que ça soit la meilleure manière. Si vous avez des idées, je suis tout ouïe.

Pour vous, c'est quoi l'interface d'admin idéal ?

Je crois que c’est une bonne idée de pouvoir heberger la partie d'administration sur un autre serveur. Ça permet d'utiliser Heroku gratuitement étant donné que la rapidité n'est pas un élément critique et qu'il y a peu d'utilisateur simultané.

Au niveau de l'interface, je trouve que celle que j'ai fait est bonne. J'utilise https://github.com/lorenzofox3/Smart-Table . Avez-vous de meilleurs idées ?

Une plus-value que je pourrais voir serait le fait de comprendre la base de données. Je pense à un outil pour lequel il serait possible de générer les modèles à partir des tables trouvées. Par exemple, s'il trouve une table "users", il génére le modèle "User" en créant un fichier. À chaque fois qu'il trouve une colonne "association_id", il génère un "belongs_to" et un "has_many". Il y aurait un intérêt pour les applications non-rails. Dans l'idéal, il serait possible de générer une application contenant une interface d'administration en quelques instructions. La difficulté serait pour les différents standard mais j'imagine que faire les relations manuellement dans certain cas serait pas si mal. Évidement, pour personnaliser, il faudrait connaître Rails.

Qu'en pensez-vous ?

Bonne soirée à tous,
Guirec.

 

Le 2015-04-27 21:25, Florian Dutey a écrit :

[Guirec Corbel]

Je viens de voir qu'il existait https://github.com/bosko/rmre et https://github.com/wnameless/rare_map permettant de générer des modèles à partir d'une base de données. Je pense que, si ça fonctionne bien, générer une application Rails à partir d'une base de données ne doit pas être trop dur.

S'il y a du monde intéressé, je crois que je vais me lancer là dessus. Si ça vous intéresse, dites le-moi.

[Matthew Nguyen]

La derniere fois que j'ai utilise une interface admin, j'ai remarque qu'il manquait la gestion d'images (pour une galerie photo par exemple). Je me rappelle que je devais uploader les images une a une et il était assez difficile de modifier l'ordre des images dans l'album sans une lourde customisation.

Apres c'était il y a deux ans et ca a peut-être change depuis.

En tout cas je ne serais vraiment pas contre une interface admin qui gère les photos/fichiers out of the box et avec des uploads via javascript.

J'ai aussi remarque que les interfaces admin étaient très difficiles a comprendre pour les clients. Au final, il fallait tout customiser voire réécrire completement l'interface pour que l'utilisation soit suffisamment simple et que le client comprenne comment l'utiliser.

Par contre je n'ai aucune idée de comment implementer ca...

[Sylvain Abélard]

Disclaimer : ma boîte fait un robot de production d'applis Rails automatique à partir d'une base de connaissances.
La première partie et la plus simple c'est de générer le modèle avec une BDD et réciproquement.

> Je viens de voir qu'il existait https://github.com/bosko/rmre et https://github.com/wnameless/rare_map
> permettant de générer des modèles à partir d'une base de données. Je pense que, si ça fonctionne bien,
> générer une application Rails à partir d'une base de données ne doit pas être trop dur.

> S'il y a du monde intéressé, je crois que je vais me lancer là dessus. Si ça vous intéresse, dites le-moi.

C'est facile, mais ça ne répond jamais directement aux besoins des clients.
De toutes façons nous les codeurs sommes rarement assez ergo/UX pour être bons là-dedans.
(il faudrait avoir X années d'expérience mais le codeur français est incité à devenir manager avant -- le plus souvent)

Fais gaffe à l'abus de métaprog, c'est une galère en perf et en sécu.
J'en parle justement au prochain ParisRB ;)

> La derniere fois que j'ai utilise une interface admin, j'ai remarque qu'il manquait
> la gestion d'images (pour une galerie photo par exemple). Je me rappelle que je
> devais uploader les images une a une

Il doit bien avoir des uploaders de masse.
Quand on a codé une sorte d'interface proche d'un filepicker ça ne nous a pas pris super longtemps.
Ajouter un upload "un seul fichier zip qui se décompresse côté serveur" n'est pas trop dur non plus.

> et il était assez difficile de modifier l'ordre des images dans l'album
> sans une lourde customisation.

Je crois que ça se code directement au cas par cas.
Ce qui sera bon pour ton 1er client ne le sera probablement pas pour le suivant.

J'ai aussi remarque que les interfaces admin étaient très difficiles a comprendre pour les clients.

Pour les développeurs aussi : la plupart croient encore qu'on s'en sort avec une règle, puis une règle, puis une autre.
Alors que 9 fois sur 10 il leur faut une state machine.
 

Au final, il fallait tout customiser voire réécrire completement l'interface

pour que l'utilisation soit suffisamment simple et que le client comprenne comment l'utiliser.

Par contre je n'ai aucune idée de comment implementer ca...

Les diverses solutions mentionnées ici sont pas mal.
Mais le souci c'est que tu as toujours des histoires de droits (clients, employés back-office, manager, admin) plus ou moins tordues.
À ce moment-là l'interface de chacun de ces 4 profils devrait pouvoir être différente, parfois subtilement, parfois drastiquement.

++

[Florian Dutey]

D'experience, j'ai commence rails en 2007, j'ai decouvert ajax scaffold en 2008 et j'ai arrete de l'utiliser en.... 2008. Je trouvais ca absolument fantastique au depart et tres rapidement j'ai compris que les admin auto-generees (et tous les trucs magiques auto generee "on the fly" qui plus est) c'est mal, ce sont d'ailleurs un des premiers trucs que j'ai arrete d'utiliser. Et pourtant il me faut longtemps pour adopter un truc et encore plus pour m'en defaire. J'ai continue a utiliser prototype jusqu'en 2010 en pensant que c'etait genial.

Les admins donc, c'est "bien" pour faire du prototyping mais ca s'arrete la. Et encore.... Parce que des que tu dois faire un truc complique, tu droppes l'usage de l'outil (ou alors tu essaies d'adapter l'outil mais la, c'est du ressort de la psychiatrie), mais pour une page seulement et tu dois maintenir 2 systemes, avec tous les probleme que ca implique.

D'ailleurs, quand je dis que ces outils sont horribles et ont un scaling absolument epouvantable, je parle meme pas du frontend. La ca depasse l'entendement en terme de complexite des lors que tu as un truc un peu fancy.

Pour etre tout a fait honnete, je n'ai JAMAIS utilise active admin, j'ai vite fait parcouru leur doc et j'ai zappe presque aussitot parce que ca n'apportait rien de nouveau sous le soleil. Meme outil, memes problemes (compare a active scaffold et ajax scaffold), absolument aucune innovation si ce n'est l'interface qui est un peu plus poussee. 

Ca oblige tes devs a apprendre un DSL complet, tout ca alors qu'a terme - a moins d'avoir une toute petite application avec tres peu d'evolution - l'outil sera de toutes facons degage du projet.

Ma philosophie, c'est autant perdre un peu de temps, developper l'admin "a la main" en sachant qu'on part sur du CRUD tabulaire mais que tres vite, on va sortir de ca et qu'il faut pouvoir s'adapter rapidement au besoin du client. Avec un AA (tu noteras que c'est aussi les initiales des alcooliques anonymes) like, ton client sera tres surpris le premier sprint qu'il faille "si peu" de temps pour developper autant de choses, mais quand il va s'entendre dire plus tard qu'il a fallu 5 mecs a plein temps pour lire des milliers de page de doc et choisir un plugin bancal developpe par un guignol dans un coin et qui n'a jamais vraiment ete teste juste pour ajouter un upload de fichiers ( ;) ;) ;) ;) ;) ) et que maintenant "voila la facture mais on vous fait un prix parce qu'on est cool", ta credibilite / reputation risque d'en prendre un sacre coup.

Sorti de cela, pour faire un retour plus direct sur ton code:

Je comprends absolument pas l'utilisation d'angular couplee a celle de fichiers .js.erb. Avec tout le respect que je te dois, tu as du louper un truc dans l'histoire. Les rjs (ancien nom en rails du fait de controler la vue depuis le serveur) sont un pattern absolument affreux, pour pas dire diabolique qui est a eviter a tout prix. Pour les avoir utilise pendant 2 ans et en etre revenu, je peux te dire que chaque fois que j'en vois, mon coeur saigne (adieu la teigne). Et angular est cense se charger de la vue, ton serveur ne devrait justement pas avoir a le faire (sinon quel interet d'utiliser angular).

Quand a angular lui meme, c'est toujours un choix que je questionne. Le fait que ce soit tres incompatible avec coffeescript, qu'on ne puisse pas minifier le js (ou tres difficilement), que ce soit une vision super java et pas du tout javascript (serieusement, le truc c'est Spring dans un navigateur), que ce soit le serveur qui genere les templates a la demande etc.... Autant de raisons qui font que je vomis pas mal ce truc. Qui en plus va etre reecrit d'une maniere que je trouve encore plus infame que le premier....

Tout ca sonne tres negatif et je m'en excuse, j'ai juste l'impression que t'es en train de reinventer la roue et que tu perds ton temps mec :)

[Guirec Corbel]

Bon, je crois que c'est assez clair, je vais trouver un autre projet sur lequel je vais contribuer...

Florian, au niveau de Angular, j'avoue que c'est un reliquat du passé. J'ai commencé par faire un outil que tu dis, avec Angular en Frontend et Rails en Backend, puis j'ai voulu utilisé simple_form parce-que je l'adore, puis finalement c'était plus simple de faire un js.erb.

Merci à vous pour vos commentaires !

[David Demonchy]

Je trouve ce fil très intéressant sur plusieurs points.

Ma première réponse fut aussi tranché que les autres pourquoi une autre gem pour une admin (perso, je faisais les miennes à la main, ça correspondait au moins à ce que mon client en voulait.)

Puis ce fil dérive lentement et surement non plus sur l'utilisation d'une gem pour l'admin, mais de techno à part entière.

Et là pour moi ça devient très intéressant.

On se rend, aussi, compte qu'une techno devient assez vite obsolète ou simplement has been.

 

Je bosse en ce moment sur du e-commerce avec magento, (j'ai déjà pu l'imposer à Prestashop) donc je ne vais pas trop me plaindre.

 Mon but, parce que je ne me plais pas du tout sur du php, serait de pouvoir migrer vers Spree.

Mais pour ça il va falloir avoir au moins les mêmes fonctions que l'existant. (gestion déclinaison, paiement bancaire, transport etc), régle panier, régle produit, souplesse template

Bref il va y avoir un gros travail en amount avant de prendre la décision de basculer. et je ne suis pas sur d'avoir gain de cause au final.

Et là on parle nouvelle techno frontend, d'api et compagnie.

Alors j'essai de me maintenir à minima au courant des nouvelles techno, beaucoup moins à les tester.

Mais du coup que faire et comment  et avec quoi !

Je vais faire un nouveau post pour ça.

Bref d'un simple post, pour la création / avis sur une nouvelle gem, on en arrive a de beaux échanges.

--
David DEMONCHY
fusco_fr  (twitter)
--

[Guirec Corbel]

Tu as effectivement l'air de travailler sur un solution de ecommerce. Plutôt que d'écrire "en amont" tu as mis "en amount". Tiens nous au courant de l'avancement de ton projet.

[Florian Dutey]

Je suis dans le metro en partance pour laeroport donc pas le temps de chercher mais il existe une solution ecommerce a base dapi json. Tu subscribes sur leur site et tu dev que le client.

Ca te permet de dev une interface super custom pour ton client. Pas besoin de scaler, cest teste en live par des tonnes de user.

Lavenir pour les soluces ecommerce, cms etc... est de ce cote a mon avis.
Et clairement ca donne un argument supplementIre pour dev en spa.

Seul point noir, tas pas la main sur le scaling et la securite