aio-libs
Implement admin view generator
It is possible to generate config.js base on information about schema. Possible solution would be to use regular jinja2 templates to render js mark up.
It seems like this is mostly done already. There is config.j2 which is a Jinja2 template generating the Javascript needed. However, I'm having some integration problems with this.
Firstly, the demos generate the file and write it to the filesystem for serving under admin/config. I like to avoid writing to the filesystem at runtime, since in many deployment situations that's not possible. I want to render this template at request time, and perhaps cache in memory (altho I'm not sure I care about first-page load-time for admins).
Along the same lines and related, I don't see why admin/config should be shared with the world. Is some Javascript reading those yaml files? Surely that's confidential stuff.
My proposal:
- [ ] completely remove the static route for
admin.config - [ ] move
config.jsto be provided byAdminHandlerdynamically (call a coroutine) - [ ] allow library user to provide a handler for that endpoint, perhaps with default of
layout_utils.generate_config - [ ] update demos to use that to call that instead
- [ ] adjust templates to match the above
Any thoughts?
Have no hard opinion on that matter, my idea was tracking changes in UI with git, your idea fine too.
Tricky part is foreign keys, which requires user interventions, we can infer this information sometimes, but for robust solution, user should tweak something, like classes in Django. My idea was that we generate config.js and let user to tweak it and then as next step may be create admin builder in python.
Yeah, it's not a simple problem. Maybe as a half-step, we could add more Jinja2 blocks to config.j2 so each part can be overridden individually? Still it does looks like some hard-coding will always be required.
Easier to tweak JS and have immediate result in browser then fight with Jinja2, at least this is my experience. Those blocks may be helpful as a half-step, but before that we need at least an idea how high level api should look like.