tmbb
I’ve been working on two packages (not on hex.pm yet) to build admin interfaces for phoenix apps:
-
bureaucrat - which contains a bunch of generators to create very feature-rich CRUD views for your resources (with filtering, sorting and proper pagination out of the box)
-
forage (the name comes from the rummage package) - which does the bulk of the work by allowing easy creating of dynamic ecto queries based on plug query parameters. It also contains widgets which make it easy to create search filters, pagination widgets, etc. It acts as a bridge between the form in the frontend and the ecto queries in the backend. Unlike rummage, it’s coupled to plug applications, while rummage tries to be frontend-independent. I don’t think that in the current state of the elixir ecosystem decoupling it from plug is worth it.
Documentation is severely lacking, but those who are interested can look at an example project here: GitHub - tmbb/bureaucrat_demo_app: Demo app for Bureaucrat · GitHub
The packages lack a lot of documentation, and I’ll work on that over the next weeks now that I’m happy with the functionality.
Roadmap
I’m planning on doing the following:
-
Documentation, documentation, documentation…
-
In particular, documenting forage’s functionality, because it can be useful outside Bureaucrat. I do try very hard to make it work as a black box, that is, as longa s you use the correct widgets in the frontend things should just work, but people who want to extend it need some guidance.
-
Make Paginator (a library which I use for pagination) support ecto 3.
-
Improving forage so that it is less dependent on the Repo. Everything should work with “raw” ecto queries independent of the Repo. That will probably require some PRs to the paginator package which I use for pagination.
-
Make bureaucrat play better with many-to-many relations. That will require working mostly on forage, and only minor changes to Bureaucrat itself
-
Make bureaucrat independent of JQuery, and find a better way to packaging the necessary Javascript. The current generated templates get all JS and CSS from a CDN and embed some inline Javascript to make the Select2 widgets work.
-
Write a proper tutorial, based on [this tutorial](Quick Minimal Application — Flask AppBuilder, for the Flask application framework (which is a python project)
Trending in Announcing
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
hauleth
I see a problem here, as there is already one Elixir project named Bureaucrat.
tmbb
I could swear I had looked that up on hex.pm… Well, I have to pick some other name then.
EDIT: I accept suggestions
EDIT2: maybe I should squat on
foragetoo, before someone claims itAstonJ
Will it be like RailsAdmin? If so what about PhoenixAdmin?
tmbb
I have never used Rails (much less RailsAdmin), so I don’t know how it compares.
Additionally, PhoenixAdmin sounds like something very “official”, like if it were the thing everyone shoul be using. I don’t think I want that kind of responsibility
But thank you for you suggestion. I’ll think about it.
AstonJ
Understandable
I’d definitely look at RailsAdmin for inspiration tho - although I haven’t used it myself for a while I remember how easy to set up it was, you could get away with almost zero configuration from what I remember, very plug and play
tmbb
There is a tradeoff between “being very plug and play” (AKA magic) and “being easily customizable”. If you look at the readme of the sample project above, you’ll see that it requires a couple of easy changes to your router and to your repo, but most of the work is done by phoenix-style generators.
Such generators will generate context, schemas, views, controllers and templates for your modules. This results in A LOT of extra lines of code for your project. I could cut back on it by encapsulating most of that in a macro, such as:
gen_admin(MySchema), and that wouldn’t pollute your application’s source with the extra files. But then customizing that would be hell. Dumping literal files into your source is still the easiest way of allowing for customization.I could save on lines of code by dumping files containing modules with lot’s of overrideable function calls. That’s what most python packages do: they have some classes that implement the full behaviour you want and make you override methods in order to customize the functionality you want. But having the source of the original “method” (in elixir’s case, function) in front of you helps with customizability.
tmbb
I’ve taken a look at a demo app generated with Rails admin (here: http://rails-admin-tb.herokuapp.com/admin/). I support pretty much the same functionality, although not in such an elegant way. RailsAdmin probably does most of the work inside its classes, while I just dump code into your project. I think I support some things RailsAdmin doesn’t, like more specific filters, but that might just be the app I’ve seen.
The theme in my dashboard was copied from AdminLTE, which I got to know because of ExAdmin, by @smpallen99, without which this package wouldn’t exist, even though we share no actual code
. I’ve also taken inspiration from torch, which also uses generators and from which I’ve copied the frontend part of the filters (again, without copying any actual code).
My project is actually very similar to torch. I think the main difference is that I support association filters, while torch doesn’t, because my query builder (forage) might be a little more powerful than theirs (filtrex). I also like my templates better, even though they could use some improvement.
I should have acknowledged all these sources of inspiration in the Readme, but I didn’t have the time. I’ll be sure to include all sources of inspiration, as well as competing libraries and why I haven’t used them.
Also, something I’ve forgotten to mentions. Because this project uses normal Phoenix abstractions, it’s trivially easy to have muitiple admin interfaces. The admin interfaces are namepaced according to the context they refer to, and you could have multiple ones, such as
Admin,Staff,Moderator,User, etc, each protected by different permissions and all of that.dimitarvp
I’d use something like
bureacraticorfrontdesk.Well, this is open source. Assuming a car doesn’t kill you on the spot one morning, you can always hand ownership over to somebody else. I see nothing wrong with a bit more official-looking name.
peerreynders
Go for an “adjacent” name then, for example:
… just as an example.
jfrolich
Very interested in this. Using
ex_adminnow, but the projects dead.Do you have screenshots for the admin interface?
I think it would be better not to generate code, but use macros that generate the code. It’s way more maintainable, otherwise you’re stuck with a lot of scaffolds in your app, and it’s way harder to upgrade when there is more functionality. Just provide the minimal information to be able to build the admin interface. I think ExAdmin in that sense is pretty neat (execution is not great though).