IRC logs for #farmOS, 2022-06-18 (GMT)

2022-06-17
2022-06-19
TimeNickMessage
[05:00:06]* tool172[m] has quit (Quit: You have been kicked for being idle)
[05:00:35]* AnasHaddad[m] has quit (Quit: You have been kicked for being idle)
[13:46:56]<mstenta[m]>paul121: I got it working!
[13:54:15]<paul121[m]>Woo! What was the trick?
[13:54:49]<mstenta[m]>Setting `'#parents' => $element['parents']` in the `value` element
[13:54:58]<mstenta[m]>* => $element['#parents']` in
[13:55:27]<mstenta[m]>That basically tells Form API to treat the value as the element's canonical value
[13:55:34]<mstenta[m]>Regardless of whether or not `#tree` is ued
[13:55:41]<paul121[m]>Ah okay I was curious about #parents!!!
[13:55:44]<mstenta[m]>s/ued/used/
[13:55:46]<paul121[m]>Perfect
[13:55:50]<mstenta[m]>And then a few minor tweaks to `GeofieldWidget`
[13:55:59]<mstenta[m]>Just to respect the new structure
[13:57:42]<mstenta[m]>I actually found the ansewer in core's `Radios` element, and corresponding `OptionsWidgetBase` (for Field API)
[13:58:04]<mstenta[m]>the `radios` element essentially creates a single element with a bunch of single `radio` elements inside it
[13:58:55]<mstenta[m]>And the `OptionsWidgetBase` uses a custom `#element_validate` to then do a bit more transformation into the format that Field API needs
[14:01:12]<mstenta[m]>[OptionsWidgetBase](https://git.drupalcode.org/project/drupal/-/blob/dc4e2a8b36c8b812a8a0315...)
[14:01:18]<mstenta[m]>s/[OptionsWidgetBase](//
[14:01:42]<mstenta[m]>https://git.drupalcode.org/project/drupal/-/blob/dc4e2a8b36c8b812a8a0315...
[14:01:53]<mstenta[m]>Notably, now it works regardless of `#tree`
[14:02:56]<paul121[m]>Wonderful!
[14:04:11]<mstenta[m]>Will push updated branch shorty...
[14:04:33]<mstenta[m]>Still need to finish up docs, but if you have a chance to check out this commit and give the rest an overall thumbs up, then I can go ahead and merge when I'm done
[14:04:46]<mstenta[m]>I feel pretty good about this! :-)
[14:05:06]<mstenta[m]>Tested parsing a KML file into geofield too
[14:05:30]<mstenta[m]>(Would be great to get automated tests for those things... but probably won't be able to add that this round)
[14:09:33]<mstenta[m]>https://github.com/farmOS/farmOS/compare/2.x...mstenta:2.x-map-form-element
[14:09:59]<mstenta[m]>Here is the relevant commit: https://github.com/farmOS/farmOS/commit/9d817873264215253fe4245766a52579...
[14:14:55]<paul121[m]>Hmm sorry only on my phone, but I'm surprised to see the $delta reference removed from the GeofieldWidget. It seems like that is an important part of field widgets. We don't have multivalue geometry fields so it's not a big issue there, but makes me curious about this....
[14:14:55]<paul121[m]>Did you try adding farm_map_input to a nested array in a quick form? Just to make sure it uses the proper parents?
[14:17:16]<mstenta[m]>Ah hmm - let me try that
[14:17:33]<mstenta[m]>And maybe I can try a multi value geometry field too - good point
[14:18:10]<mstenta[m]>What do you mean by "adding farm_map_input to a nested array in a quick form"? Like put it into a fieldset with #tree = TRUE?
[14:18:19]<paul121[m]>If it's just multivalue geometry fields that don't work that's not as big of a problem.. maybe not worth blocking
[14:19:02]<mstenta[m]>Yea, but you're right... and if we can support it we should. Maybe the bigger question is: do multi value geometry fields work BEFORE this change?
[14:19:14]<mstenta[m]>I never tested it - are you aware of any existing limitations?
[14:19:36]<paul121[m]>Not sure!
[14:21:24]<mstenta[m]>> adding farm_map_input to a nested array in a quick form... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/302173ba55...)
[14:21:39]<mstenta[m]> * > adding farm\_map\_input to a nested array in a quick form... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/4f3bcc96dd...)
[14:26:14]<mstenta[m]>Hmm. Well multi-value geofields do not work.... But let me try checking out 2.x and testing on that too.
[14:26:23]<mstenta[m]>Still - I think you're right that `$delta` should stay
[14:26:42]<mstenta[m]>(basically just remove the `value` bit, but leave `[$field_name, $delta]` in both places
[14:26:54]<mstenta[m]>i'll test that on a single value field as well
[14:28:11]<mstenta[m]>works (with `$delta` as described) on single-value field
[14:28:21]<mstenta[m]>so maybe multivalue geofields are just broken... testing on 2.x now...
[14:28:38]<mstenta[m]>if so, i'll open a separate bug report for that and we can figure it out later
[14:29:03]<paul121[m]>Cool. Yeah not as worried about that
[14:29:05]<paul121[m]>I gtg!
[14:29:11]<mstenta[m]>Cool thanks for the eyes!
[14:29:34]<mstenta[m]>If it's alright with you paul121 I'll merge this after these bits
[14:31:14]<paul121[m]>Oh.. are we deleting both geofield and geofield_widget? 😁
[14:31:33]<mstenta[m]>No just `geofield_widget`
[14:31:44]<paul121[m]>Oh nvm! Renaming the geofield behavior. Great
[14:32:04]<mstenta[m]>https://github.com/farmOS/farmOS/commit/a1a015cc580b3d64e9e1c6087d9c389c...
[14:32:11]<symbioquine[m]>mstenta[m]: I'm not sure "multivalue geofields" make much sense for single records in the farmOS data model...
[14:32:50]<symbioquine[m]>There's definitely a use-case for something like that though in quick forms and similar where additional data can be associated with each geometry.
[14:32:59]<paul121[m]>mstenta[m]: Yep
[14:32:59]<mstenta[m]>symbioquine: I agree. And we will probably never use them. But if the widget we provide is broken on multi-value fields it means NO ONE can use it.
[14:33:02]<mstenta[m]>So low priority... but still technically a bug.
[14:33:15]<mstenta[m]>Ah yes and in quick forms it works!
[14:33:27]<mstenta[m]>Just Field API that seems to be broken at the moment... testing 2.x branch now...
[14:33:53]<symbioquine[m]>mstenta[m]: Ah, I might not have been understanding the case you were talking about then...
[14:34:17]<mstenta[m]>AH DANGIT lol - multivalue geofields work in 2.x 🤦
[14:34:31]<mstenta[m]>So this actually breaks them :-(
[14:34:35]<mstenta[m]>Oh well... another thing to debug then...
[14:35:40]<mstenta[m]>Yea sorry symbioquine - there are two contexts: Form API (eg quick forms, other custom forms, etc) and Field API (entity forms) - it's the Field API mutivalue geofields that aren't working.
[14:35:55]<mstenta[m]>And we don't currently use "multivalue" geofields anywhere in the farmOS data model - nor should we ever IMO
[14:36:09]<mstenta[m]>But someone may want to add a Geofield to their own entity and use the farmOS map widget
[14:36:32]<mstenta[m]>("multivalue" == "Allow unlimited values" where you can click "Add another" and another map shows up to draw on)
[14:37:01]<symbioquine[m]>Makes sense
[14:37:30]<symbioquine[m]>but it would only break if they set the cardinality to >1 or unlimited right?
[14:37:34]<mstenta[m]>Yep
[14:38:02]<mstenta[m]>Which... I just tested, and technically that does work currently (in our 2.x branch), but does not work in this new branch... so I should debug it
[14:38:45]<mstenta[m]>Probably something simple...
[14:39:43]<symbioquine[m]>worst case could be using a `hook_form_alter` to throw an error that says multi-value Geofields aren't supported in farmOS and suggest that a single geofield that produces a geometry collection might be sufficient...
[14:40:40]<symbioquine[m]>Little hacky, but at least it would head-off other folks troubleshooting while it's still an outstanding bug.
[15:01:17]<mstenta[m]>OK! Got it working. :-)
[15:02:20]<mstenta[m]>Actually backtracked a little bit to the way we were trying to do this originally... using the validate method of the element (NOT the geofield) to set the value. And NOT using `#parents`...
[15:03:49]<mstenta[m]>`#parents` was the cause of the issue in multivalue geofields... because FormAPI was automatically adding another sub-element for `_weight` and that was then getting used for the value instead of `value` (not exactly sure I understand why... but that's what was happening)
[15:07:19]<mstenta[m]>ahhh wait... maybe not
[15:07:20]<mstenta[m]>oy
[15:18:00]<mstenta[m]>Huh. OK. Well I did get it working... drove me a little nuts for a second there...
[15:18:21]<mstenta[m]>I'm not sure I love how it's working. But it is working.
[15:21:28]<mstenta[m]>I'm going to need to give this some more thought....
[15:35:02]<mstenta[m]>Eh... well... here's a new commit for review if you have time/interest paul121
[15:35:23]<mstenta[m]>https://github.com/mstenta/farmOS/commit/e70b092c0590dccb1914fbe092b653a...
[15:36:45]<mstenta[m]>Main differences from the previous approach:
[15:36:45]<mstenta[m]>- No longer using `#parents`
[15:36:45]<mstenta[m]>- Setting the string value in the `farm_map_input` form element's validation method
[15:36:45]<mstenta[m]>- Overriding `#element_validate` in `GeofieldWidget` to NOT use `farm_map_input`'s validation method 🤷
[15:37:09]<mstenta[m]>The last point is the only bit I feel weird about...
[15:37:44]<mstenta[m]>But with that, and the only minor changes (in `FarmMapInput::valueCallback()` and `GeofieldWidget`), everything appears to be working
[15:37:54]<mstenta[m]>s/only/other/
[15:40:18]<mstenta[m]>It does all make sense... not that "weird" I suppose... just a touch less elegant maybe. But that might just be the nature of these unique circumstances we're navigating.
[15:40:35]<mstenta[m]>Anyway - signing off. Take a look if you are able. Thanks again for helping with this! :-)