I have been spending the past few days looking for a good admin package. I’m glad you posted this now!
As far as names go I recommend PhAdmin!
JoeZMar
tmbb
ExAdmin’s (questionable) execution is a direct result of the way it uses macros instead of generators. Using macros makes it terribly hard to customize the admin interface.
In my experience with python admin interfaces which use classes with overridable methods instead of clde generation, there are so many little things you want to customize that generating a scaffold feels like a good solution.
Bureaucrat is quite minimal. I expect most improvements to come from the forage package, which is a normal package with normal functions (no generators). Your scaffolding will remain useable even if forage is upgraded.
I can add both screenshots and a video for the more dynamic parts.
0
tmbb
tmbb
In particular, I think the templates should always be generated using generators and not macros, because you end up customizing those a lot.
I can see the controller and the context accessors being generated with macros, though.
The controller could just be:
defmodule MyApp.Admin.UserController do
use Bureaucrat.Controller
end
with the controller actions implemented as defoverridable functions which the user could override.
I could have the same for the context accessors:
defmodule MyApp.Admin do
alias MyApp.Admin.User
use Bureaucrat.Context, schema: User
end
again with defoverridable implementations for the functions, and maybe some options like:
defmodule MyApp.Admin do
# read-only context
alias MyApp.Admin.User
use Bureaucrat.Context,
schema: User,
except: [:update, :create]
end
I’ve decided to go with generators that generate everything without many macros brcause the architecture tha Phoenix 1.3+ pushes forward is very dependent on generators anyway.
Not that modules are “hidden” behind contexts, I have to generate a context file with accessors and a new model (i.e. schema) inside that context. That lends itself naturally to the use of code generators like the default ones that Phoenix provides.
What I could do is have a switch (say, --magic or --succint) which would cause the generators to generate very minimal files with macros like the ones above. I would accept a PR with that functionality, but I’not going to work on it myself for the time being.
I have more important things to do, namely add tests to both packages. I’ve been “testing” them only with end-to-end manual integration testing (aka playing with them)
2
josemrb
Do you plan to generate JavaScript files too?
I’ve been working on similar project with the same approach but the front-end is going to use JS + jQuery + plugins.
0
tmbb
The default template includes JS from a CDN and some custom (constant) Javascript. I haven’t had the need to generate any dynamic Javascript.
1
tmbb
More specifically, I need JQuery for the Select2 widget, which I need for my association picker. The JS for both JQuery and Select2 coms from CDNs. The little snippet of custom Javascript I need to customize Select2 for my needs is embedded directly in the template.
JQuery is quite a big dependency, but all good custimizeable select widgets I’ve found depend on JQuery. I need one of the good widgets because I need features like remote data access (to load associations from the server) and the ability to customize pagination. That way you can use these widgets, tables with millions of rows and suff like that.
You might want to contribute to either forage or bureuacrat, then. Documentation is not the best, but it will get there.
1
tmbb
A question. Let’s say I have table A with a one-to-one relation to table B. In the crud page for A, I need a select witdget to (dynamically) request models from B. That requires an HTTP request to a controller. My question is: should I request it to the ControllerB, or should I have a special action in ControllerA?
Currently the functionality to request the B data for the select widget lives in ControllerB
This isn’t set in stone, of course. I’m asking about what the generator should generate by default. The user can always customize the generated controller and routes.
0
tmbb
I should explain why I’ve started my own admin framework instead of contributing to one that already exists.
The main reason is that I didn’t like any of the current dynamic query generators. Some used String.to_atom() inplaces where it was hard for me to audit. Some used a format for query parameters which I didn’t like. Some had good functionality in the backend but no easy-to-use widgets in the frontend to generate those queries (my forage library couples the frontend to the backedn by design; in theory the user doesn’t even need to know the query format if we’re talking about a Plug app). Some had little to no documentation.
Regarding the admin generators themselves, Talon would be the top contender, but I’ve found out that the use of Slime templates overcomplicates the design. My library only supports “vanilla” HTML. Indentation-based languages get very complex very quickly, and until I find one I’m satisfied with, I don’t want to supoort such templates. Talon also doesn’t support pagination in many-to-one relations, and supoorts much simpler filters than I do. With some advantages, of course, like real-time search. I intend to implement it when Phoenix LiveView goes, well, live, if it turns out to play nice with the JS widgets I need. Also, one of the design goals of Talon is to be a “general frontend for CRUD apps”. I have no such pretentions. Forage is a general dynamic query builder. Bureaucrat is a (very customizable) admin framework. If you want a CRUD framework on top of forage, you can implement your own.
Another strong contender is torch. It uses generators (like Bureaucrat), but it has some problems. Templates are more verbose, and filters don’t seem as powerful. I also didn’t like their query builder very much.
Anyway, when I assume that I need a new query builder, it makes sense to couple the admin “frontend” to the query builder.
0
stefanchrobot
Please do!
In general: great project! I have an app that’s basically RailsAdmin over a PostgreSQL database so this would be a great case for replacing it with Elixir.
0