Solidus Adminland
Dies ist ein Vor-Alfa-Stadium und kann in Zukunft geändert werden.
Dies beginnt als unterhaltsames Projekt für interne Zwecke, um eine zuverlässigere Version des Solidus_backend-Admin-Panels zu erstellen. Solidus verfügt über eine großartige Kernkomponente und eine batteriebetriebene Admin-Schnittstelle, aber unserer Meinung nach und aufgrund unserer Anpassungen fehlt dem Admin-Juwel die Designstruktur, um eine echte Nebeninfrastruktur für die Kommunikation mit der solidus_core-Struktur zu sein.
Merkmale
- Wunderschön und einfach zu bedienen (UX ist wichtig)
- Hotwire Turbo angetrieben ⚡️
- Anregung mit Importmaps für kleine Sparkles
- Filtern leicht gemacht mit Ransack
- Stapeloperationen wie Zerstören
Warum das Rad neu schreiben?
Wie gesagt, unserer Meinung nach hat solidus_backend auf so viele Vorbehalte des Festhaltens an Bibliotheken zurückgegriffen, die auf den Spree-Fork zurückgeführt wurden (Deface, ich schaue dich an!) und diese Struktur ist zu streng für diese Entscheidungen:
- So viele der Filter mit Ransack sind mit dem Digest der benutzerdefinierten Parameter unübersichtlich
- Kann mit „Makros“ (:manage, :admin) und nicht mit echten CRUD-Routen verwendet werden und hält sich nicht an die Konventionen des MVC-Musters.
- Die Bearbeitung von Produkten, Bestellungen und Werbeaktionen basiert auf Ajax mit Backbone und nicht auf einem konventionelleren CRUD-Verhalten.
- Nicht „wirklich“ Turbo-kompatibel: Turbolinks wurden in Hotwire entwickelt und sind derzeit nur ein Ausschnitt für die korrekte Ausführung von Javascript-Skripten.
- Starker Einsatz von Javascript-Remoteausführung von Rails-UJs und „Remote: true“ anstelle einer saubereren und vorhersehbareren HTML-Antwort mit Turbo. Ich denke, dass Remote kein guter Ansatz ist, da dadurch Javascript-Code in die Browserkonsole eingefügt wird, in der Hoffnung, ausgeführt zu werden, und für mich eine potenzielle Sicherheitsbedrohung durch Cross-Scripting darstellt.
Wie Sie sehen, ist solidus_admin ziemlich alt und was die Überarbeitung von solidus_frontend mit solidus_starter_frontend betrifft, ist es Zeit für ein umfangreiches Experiment und eine Erneuerung!
Versuchen Sie, ein neues Solidus_backend-Gem zu erstellen?
Irgendwie aber nein . Ich beginne dies zunächst einmal als alternatives Projekt, weil es sich um ein Alpha-Projekt handelt und sein Ziel darin besteht, neben einem batteriebetriebenen Backend mit geringer Kopplung mit dem Rails-Framework, aber auch ein ziemlich strukturiertes Adminland-Framework für Erweiterbarkeit und UI-Anpassung ohne Headdacle anzubieten . Ich möchte, dass es sich stärker auf die vom Eigentümer des Hostprojekts ausgewählte Bibliothek verlässt, um eine einfache Integration ohne allzu große Einschränkungen zu ermöglichen.
Ok, also was ist deine Wahl? Sind Sie auch einfühlsam?
Ich denke, wir könnten uns vorstellen, dass die Adminland-Codestruktur diese Grundlagen berücksichtigt:
- Einfaches Überschreiben und Erweitern mit weniger Überschreibungen/Monkey-Patch-Ansatz. Wir sind Menschen, keine Affen!
- Vorheriges Verbot für Deface. Der Verunstaltungsansatz hat mir nie gefallen, und ich denke, es ist besser, die Benutzeroberfläche von Anfang an als modular zu betrachten und Ansichten alternativ durch Kopieren, aber nicht durch Patchen und Einfügen zu überschreiben. Für die Erweiterbarkeit eines anderen Sidecar-Tools (alle Solidus-Erweiterungen mit Admin-Abschnitten) ziehe ich es vor, einen klareren und exponierteren Point-of-Prepend zu setzen.
- Streng auf CRUD-Routen. Alles muss sich auf CRUDs Routen verlassen, die so strikt wie möglich sind, wie auch beim Ansatz verschachtelter Routen, und zugunsten der Konvention gegenüber dem Konfigurationsansatz.
- Das Hinzufügen externer Ressourcen aus der Hosting-Rails-App sollte mit einer Generator-Gerüstvorlage erfolgen.
Vor diesem Hintergrund habe ich begonnen, einige Auswahlmöglichkeiten für das „neue“ solidus_adminland-Projekt festzulegen, wie zum Beispiel:
- hotwire standardmäßig und fördert mehr als einen js-DOM-Manipulationsansatz.
- Anregung für einfache und zuverlässige Ergänzungen wie Picker, Eingabemaske und Formularvalidierungen
- Verwendung des View_Component-Gems zum Kapseln von Hilfsmethoden mit HTML-Ergebnissen (z. B. link_to oder komplexere Methoden). Ist auch für Überschreibungszwecke einfacher, als Alternative zu Teilwerten für Zuverlässigkeit und PORO-Klasse für UI-Logik
- Jeder Import von Assets erfolgt mit Rails-Importmap für einen „kein Javascript-zentrierten App-Ansatz“.
- Verwendung des Verwaltungs-Gems zur Aufteilung von Bedenken zwischen Darstellung (mit *Dashboard-Klasse) und CRUD-Routen für anzuzeigende oder zu übermittelnde Daten
- Alle Formulare werden von FormBuilder gestaltet, wobei jedes Feld mit einer separaten Component-Klasse gerendert wird. Wenn wir oder jemand in einer Funktion ein seltsames Feld wie Dropdown-JS-Felder einfügen möchte, kann dies mit dem neuen Admininstrate::Field, FormBuilder::Component und dem Stimulus für js sparkle erfolgen?
- Aus politischen Gründen denke ich, dass wir einen hybriden Ansatz entwickeln könnten, der mit Cancan kompatibel ist, aber mit einem einfacheren Pudit-Ansatz. In unserem Fall verwenden wir action_policy gem. Es basiert auf einem PORO-Objekt, in dem wir für jede Aktion definieren können, welche Regeln für die Durchführung gelten. Es ist ein echtes Mittelstück für Controller zur Steuerung von Richtlinien über „Aufzeichnungsbereich“, „Zulässige Aufzeichnungsparameter“ und „Aufzeichnungszugängliche Routen“.
Wie Sie sehen, gibt es für jede Ressource:
- ein Controller mit demselben Namen für Standard-CRUD-Operationen
- ein Dashboard mit demselben Namen für index, new_form, edit_form und show params zur Anzeige
- eine Richtlinie, auf welchen Bereich ich mit dem aktuellen Benutzer zugreifen kann, welche Parameter ich übermitteln kann und welche Route mir für diese Ressource erlaubt ist.
... und als „konventioneller“ Ansatz könnten Sie einfach Ihre eigenen dieser drei erstellen (oder erweitern) und Ihre Geschäftslogik nach Ihren Wünschen (oder Ihren App-Anforderungen) gestalten!
Der ursprüngliche Entwurf wurde mit Bootstrap 5 mit Tabler erstellt, aber Sie können die Standardansichten von Admin/Anwendung für CRUD einfach überschreiben. Die Anzahl der Aufrufe wird möglichst gering gehalten
Roadmap
Alle Rechte an Logos und Farben stammen aus der Solidus-Pressemappe. Das Admin-Theme ist von Solidus-Website-Mockups inspiriert und basiert auf der Bootstrap 5-Version von Tabler
