Would you be interested in working on a super opinionated FlaskAdmin-type admin backend on top of Formex? It’s not too hard, just write some macros that create a controler, a view and a form type based on the schema and possibly some configuration options that overwrite the defaults.
The tricky bit is always how to add some configurability, but I think there’s a place for super simple backend that can eb generated with a couple lines of code.
Yes, I contributed some ideas to v2.0 (talon) by the same author. @smpallen99 seems to have stopped working on that a while ago and he was going the opposite direction: less magic, more generators. I think it should be the other way around: more magic, fewer generators xD If you find yourself requiring lots of customizations you’ve probably outgrown these kinds of solutions and need to design from scratch.
I think such a project should have an API like this:
but what if we want to reinvent the wheel? Anyway, I have never tried itdefmodule MyApp.MyAdmin do
use SomeMagicHere
defresource MySchema1, options: [...]
defresource MySchema2, options: [...]
defresource MySchema3, options: [...]
defresource MySchema4, options: [...]
# ...
end
It would define controllers for the resources (using macros, no code generation). Then you’d just add the stuff to the router.
defmodule MyAppWeb.Router do
# ...
require MyApp.MyAdmin
# ...
MyApp.MyAdmin.routes "admin/"
# ...
end
The :options would allow the user to customize some things, and even add extra controller actions. For example:
defresource User, options: [
extra_actions: [
change_password: &PasswordController.change_password/2
]
]
My idea was to have zero work for the default case (just define the schemas and you’re good to go) and incrementally more work for more advanced use cases. I think that FlaskAdmin or FlaskAppBuilder are good sources of inspiration.
They take tons of options, with varying levels of granularity depening on how much customization you need. You can change the field labels, the order of the fields, etc. They do all of this with class inheritance, of course, but it an be done by merging option dictionaries r keyword lists.
Years ago I built a CakePHP based admin backend generator. It worked really well and had CRUD level access control lists down to the form field. We didn’t use generators because we needed that admin interface to change as our application grew as long as we followed the proper database naming rules. You could override those at any point though.
The trickiest bit with configuration really just boiled down to being able to pass a nested map down the function chain to make deep level changes from the highest level when necessary.
With Elixir though, I’d be more concerned about properly leveraging IOLists and I’d probably go with the generator approach as well. Something like the Taggart library I just saw might be a good fit for it.
Ideally, you’d want to be able to specify configuration details for specific templates, then run a mix task to regenerate the proper template code for each one so that it follows the proper compilation process, etc.
That doesn’t sound that tricky. It’s just a job for Map.merge/2
Where do IOLists enter the picture? You use Taggart if you want, of course, but you can just generate EEx templates end compile them with Phoenix’s EEx engine, which I think uses IOLists anyway. Those templates could be compiled at macro-expansion time. Is there anything I’m not seeing here?
I might have misunderstood what you were going for when you mentioned going away from generators earlier.
Going away from generators means that you supply a minimal amount of configuration and the framework generates the rendering functions at compile time without any extraneous artifacts being written to disk. Such render functions might use EEx template, of course, but those templates are not available for customization by the user.
See…that explanation looks like a different type of generator to me. We’re on the same page though.