| [08:21:18] | * farmBOT has joined #farmos |
| [11:47:06] | <symbioquine[m]> | Dev call in about 14 minutes: https://meet.jit.si/farmos-dev |
| [16:20:14] | <mstenta[m]> | paul121 symbioquine: i started digging into creating an `inline_container` element, and i'm vacillating a little... |
| [16:20:51] | <mstenta[m]> | feels like overkill a little - since it's essentially just extending the existing container element and adding a CSS file |
| [16:21:31] | <mstenta[m]> | what if instead we just add some CSS to farm_ui_theme for this case |
| [16:22:36] | <mstenta[m]> | and tie it to container elements specifically |
| [16:23:21] | <mstenta[m]> | so from a developer's perspective, you would just do:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/a21a9fef2a...) |
| [16:23:51] | <mstenta[m]> | and farm_ui_theme (being more directly tied to the presentation layer) decides what that means (for Gin specifically) |
| [16:24:27] | <mstenta[m]> | so... it would basically be what i proposed in https://github.com/farmOS/farmOS/pull/654, except the CSS would be in farm_ui_theme not farm_quick |
| [16:25:28] | <mstenta[m]> | > feels like overkill a little - since it's essentially just extending the existing `container` element and adding a CSS file |
| [16:25:28] | <mstenta[m]> | part of me worries that we're just creating another thing to maintain with a new element, and once people start using it there's no removing it |
| [16:26:08] | <mstenta[m]> | and `'class' => ['inline'],` is pretty trivial to add in quick forms (or ANY form for that matter, if we handle the styling in `farm_ui_theme`) |
| [16:27:06] | <mstenta[m]> | AND... if someone wants to swap out Gin for something else they can... they just need to define the rules for .inline containers |
| [16:28:35] | <mstenta[m]> | > and tie it to `container` elements specifically |
| [16:28:35] | <mstenta[m]> | hmm... dang... i was assuming that `container` elements added some unique class to designate them as "containers"... but now that I'm looking at the markup it doesn't look like they do :-( |
| [16:30:06] | <mstenta[m]> | there is a form-wrapper class on the container... so maybe that could be targetted... |
| [16:31:00] | <mstenta[m]> | ACTION sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/6afe896939... |
| [16:35:14] | <symbioquine[m]> | <mstenta[m]> "and farm_ui_theme (being..." <- I was thinking about suggesting something along those lines during the dev call earlier... |
| [19:17:16] | <paul121[m]> | > <@mstenta:matrix.org> > feels like overkill a little - since it's essentially just extending the existing `container` element and adding a CSS file |
| [19:17:16] | <paul121[m]> | > |
| [19:17:16] | <paul121[m]> | > part of me worries that we're just creating another thing to maintain with a new element, and once people start using it there's no removing it |
| [19:17:16] | <paul121[m]> | that is true, this is a downside of the element approach. The good thing it provides is an abstraction though, so if the actual implementation of an inline element changes, they don't have to worry. Adding this single CSS class feels a bit fragile in the long term |
| [19:17:33] | <paul121[m]> | What if we provide a helper method for an abstraction to this? Here is what I'm doing in rothamsted module: https://github.com/Rothamsted-Ecoinformatics/farm_rothamsted/blob/43563c... |
| [19:18:51] | <paul121[m]> | one day if gin provides an inline element we can just change it to `#type => 'gin-container-inline'` or whatever |
| [19:19:47] | <paul121[m]> | ^ this is why I made the helper method... didn't want to hard-code those values everywhere.... only need to change it in one place :-) |
| [19:20:51] | <paul121[m]> | and if farmOS core adds such a feature, my existing helper method could just delegate to it |
| [19:21:35] | <paul121[m]> | Maybe farm_ui_theme could provide an ElementHelperTrait or something |