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.
boxed|4 months ago
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.
j_lubcke|4 months ago
pantulis|4 months ago
boxed|4 months ago