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 :) Le 3 mai 2015 15:26, Sylvain Abélard <sylvain.abel...@gmail.com> a écrit : > > 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. > > ++ > > > On Saturday, May 2, 2015 at 1:30:08 AM UTC+9, Guirec Corbel wrote: >> >> 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. >> >> Le 28 avril 2015 19:20, Guirec Corbel <guirec...@gmail.com> a écrit : >> >>> 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 : >>> >>> 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? >>> >>> Le 27 avril 2015 17:55, Guirec Corbel <guirec...@gmail.com> a écrit : >>> >>>> 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. >>>> >>>> >>>> Le 2015-04-27 04:38, Guirec Corbel a écrit : >>>> >>>> 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. >>>> >>>> Le 2015-04-27 02:39, Julien Grillot a écrit : >>>> >>>> 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 >>>> >>>> >>>> >>>> >>>> Le 27 avril 2015 01:59, Guirec Corbel <guirec...@gmail.com> a écrit : >>>> > 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. >>>> > >>>> > -- >>>> > -- >>>> > 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 . >>>> -- >>>> -- >>>> 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 obtenir davantage d'options, consultez la page >>>> https://groups.google.com/d/optout. >>>> >>>> >>>> >>>> -- >>>> -- >>>> 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 obtenir davantage d'options, consultez la page >>>> https://groups.google.com/d/optout. >>>> >>> >>> -- >>> -- >>> 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 obtenir davantage d'options, consultez la page >>> https://groups.google.com/d/optout. >>> >>> >>> >> -- > -- > 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 > railsfrance@googlegroups.com > Pour résilier votre abonnement envoyez un e-mail à l'adresse > railsfrance-unsubscr...@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+unsubscr...@googlegroups.com. > Pour obtenir davantage d'options, consultez la page > https://groups.google.com/d/optout. > -- -- 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 railsfrance@googlegroups.com Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscr...@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+unsubscr...@googlegroups.com. Pour plus d'options, visitez le site https://groups.google.com/d/optout .
