this looks like one of those things where it completely breaks apart if you want to do anything custom or out of line to what is intended by the framework. Causing way more headaches down the line then if you just did it yourself from the start.
this looks like one of those things where it completely breaks apart if you want to do anything custom or out of line to what is intended by the framework. Causing way more headaches down the line then if you just did it yourself from the start.
I understand that gut feeling. I've worked with many such systems. iommi is not like that though, because we HATE systems that have a nice two line demo but then immediately falls apart.
We consider any failure to scale up customization a high priority bug.
How do we handle this in practice? Nice defaults, easy to do deep customization with zero boilerplate, AND escape hatches of various forms. So if you need to just render your own template for an entire table row of form input field or whatever, you can do that. Always.
Actually, how it behaves with special cases was one of the initial requirements when it was built. A design goal has always been that there should be escape hatches. For example almost all settings can be a call-back if the value is not known up front.
From my experience with similar things built around Rails (ActiveAdmin and others) being based in a dynamic language helps and allows to accomodate a lot of customizations.
It can. But it doesn't necessarily mean that. Or maybe it means you CAN work around it, but it's cumbersome/bad to do so. Imo the Django Admin is like that: lots of ad-hoc and random customization options and lots of missing options, and it's a pain to override etc.
Agreed. When you use a web framework you are somehow trusting the ability of the creators to ship something reusable and extensible. When you use something like this now you have two groups of creators to trust that they are not only good and coding but also good at making opinionated decisions. Or, better said, you switch your trust from the framework --after all it's battle tested-- to a new group.
If one is a seasoned Django developer I guess they can take a look at the source code and judge if it suits your needs. But if it does, there is a lot of development speed to be gained.
As one of the developers of iommi I can confidently say that seasoned Django developers will be very confused by the iommi code base heh. We do things quite differently, for good and ill. I wrote about this here: https://kodare.net/2024/09/30/why-iommi-is-weird.html