| [00:13:17] | * farmBOT has joined #farmos |
| [04:31:26] | * margeo[m] has joined #farmos |
| [07:58:49] | <mstenta[m]> | paul121 symbioquine Huh... the MariaDB scheduled test run failed again last night: https://github.com/farmOS/farmOS/runs/6932792179?check_suite_focus=true |
| [07:59:14] | <mstenta[m]> | Same error as we were seeing earlier... |
| [08:00:26] | <mstenta[m]> | On a related note, I found this documentation about running tests against SQLite3 (reminded me of the old issue we had with that during parallel runs): https://www.drupal.org/docs/automated-testing/phpunit-in-drupal/phpunit-... |
| [08:00:58] | <mstenta[m]> | Not sure if there's any new information there... need to grok. |
| [09:37:30] | <mstenta[m]> | symbioquine: I'm trying to write a farmOS-map behavior that *modifies* the geometry of an existing layer. Looking for an example to work from (been a while since I've touched the JS side of stuff, I forget what's possible). Do you have any prior work on this? Or an example that comes to mind? |
| [09:38:11] | <mstenta[m]> | Specifically: a behavior that watches two lat / lon text fields, and auto-updates a layer in a map. |
| [09:38:43] | <symbioquine[m]> | mstenta[m]: Should be easy... |
| [09:39:10] | <mstenta[m]> | Trying to remember how to get the relevant layer... `getLayerByName()`? |
| [09:39:24] | <symbioquine[m]> | You just do the normal HTML/JS input watching part, then query the layer -> source |
| [09:39:40] | <symbioquine[m]> | and update the geometry of the relevant feature |
| [09:40:02] | <symbioquine[m]> | I bet I can find an example... |
| [09:40:10] | <mstenta[m]> | Yea that part makes sense I think... stuck on getting the layer in the first place 😅 |
| [09:41:19] | <symbioquine[m]> | https://github.com/symbioquine/farmOS_land_drawing_tool/blob/73300ea948b... |
| [09:41:45] | <symbioquine[m]> | https://openlayers.org/en/latest/apidoc/module-ol_Map-Map.html#getLayers |
| [09:41:57] | <mstenta[m]> | ah ok so get all layers and iterate through them to find the one i want |
| [09:42:08] | <symbioquine[m]> | https://github.com/symbioquine/farmOS_land_drawing_tool/blob/73300ea948b... |
| [09:43:07] | <symbioquine[m]> | symbioquine[m]: Obviously, there might be better ways to identify the layer you want - if you've "tagged" it somehow in a more machine readable way. |
| [09:43:29] | <mstenta[m]> | ah looks like we have a helper! |
| [09:43:29] | <symbioquine[m]> | That code I just linked would probably break if "All Locations" were translated to another language |
| [09:43:30] | <mstenta[m]> | https://github.com/farmOS/farmOS-map/blob/777758f7218499e2211c5d75c1faf3... |
| [09:44:24] | <mstenta[m]> | But yea agreed - going by name is a bit sketchy |
| [09:44:31] | <mstenta[m]> | But IIRC there wasn't really a better way to do this |
| [09:46:02] | <symbioquine[m]> | Layer objects can have arbitrary properties so we could add a way to set a "farm_layer_id" key or something like that to facilitate machine identification. |
| [09:46:21] | <symbioquine[m]> | https://openlayers.org/en/latest/apidoc/module-ol_layer_Base-BaseLayer.html |
| [09:46:26] | <mstenta[m]> | Ooh that would be nice |
| [09:49:26] | <mstenta[m]> | Thanks for the pointers! I think I'm on my way now :-) |
| [09:50:39] | <symbioquine[m]> | https://github.com/symbioquine/farmOS_land_drawing_tool/blob/73300ea948b... |
| [09:53:28] | <symbioquine[m]> | I think it would be something like; `myFeature.setGeometry(new Point([123, 456], 'XY'));` |
| [09:54:11] | <symbioquine[m]> | or maybe more efficient to modify the existing `Point` objects geometry - but it probably doesn't matter. |
| [09:54:35] | <mstenta[m]> | cool! |
| [09:55:10] | <symbioquine[m]> | s/objects/object's/ |
| [09:55:13] | <mstenta[m]> | might write this up as a blog post ;-) (cc jgaehring ) |
| [09:55:40] | <mstenta[m]> | as an example of `farm_map_input` + custom behavior in form api |
| [09:55:47] | <mstenta[m]> | with a "How To" tag ludwa6 |
| [10:24:10] | <mstenta[m]> | > I think it would be something like; `myFeature.setGeometry(new Point([123, 456], 'XY'));` |
| [10:24:11] | <mstenta[m]> | hmmmm I may end up running into the limitation we've discussed in the past... inside my behavior I don't have access to all the OL objects |
| [10:24:45] | <mstenta[m]> | i'm trying to do:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/10e9f2d2ef...) |
| [10:25:10] | <symbioquine[m]> | A work-around would be to initially add the layer with a single point using WKT/GeoJSON, then get/modify the point |
| [10:25:19] | <mstenta[m]> | :-( |
| [10:26:34] | <paul121[m]> | since it is just a point, could you manually build the WKT for the point and update the layer's WKT on change? |
| [10:26:58] | <mstenta[m]> | i'm starting without any existing geometry |
| [10:27:04] | <symbioquine[m]> | paul121[m]: You shouldn't need to do that |
| [10:27:41] | <symbioquine[m]> | You'd just use the WKT/GeoJSON loading as a work-around to get `Feature`/`Point` instances created |
| [10:28:06] | <symbioquine[m]> | Then you can set the coordinates of that `Point` just fine without any further imports |
| [10:29:01] | <symbioquine[m]> | I think it can just be `"POINT (0 0)"` |
| [10:29:31] | <mstenta[m]> | but then the map in my form starts with that point |
| [10:29:41] | <symbioquine[m]> | ah |
| [10:30:06] | <paul121[m]> | could it be an empty WKT string? |
| [10:30:14] | <paul121[m]> | to start |
| [10:30:17] | <symbioquine[m]> | doubtful |
| [10:30:41] | <mstenta[m]> | yes, but then i can't add any features, because I don't have access to the OL `Point` object in my behavior context |
| [10:31:01] | <mstenta[m]> | this is a bigger issue we need to figure out |
| [10:31:18] | <symbioquine[m]> | `map.getView().getCenter()` |
| [10:31:25] | <mstenta[m]> | oh clever :-) |
| [10:31:51] | <symbioquine[m]> | mstenta[m]: Might need to happen after the view extent updates though |
| [10:32:44] | <symbioquine[m]> | mstenta[m]: One answer is to build the behavior against OpenLayers, then it can bundle any classes it needs. |
| [10:32:49] | <symbioquine[m]> | That's what my Land Drawing tool does |
| [10:33:19] | <paul121[m]> | This is a throwback to v1, what we did was re-build the WKT layer when updating the geometry. https://github.com/farmOS/farmOS/blob/509cfb2e928ef7537977a0f53eb93ee12a... |
| [10:33:39] | <paul121[m]> | its not "perfect" but works fine |
| [10:34:04] | <mstenta[m]> | ok yea that could work paul121 |
| [10:35:10] | <mstenta[m]> | trying symbioquine's suggestion first... |
| [10:38:18] | <mstenta[m]> | > `map.getView().getCenter()` |
| [10:38:19] | <mstenta[m]> | hmm seems like this actually returns an array not a `Point` object :-/ |
| [10:41:26] | <symbioquine[m]> | > <@mstenta:matrix.org> > `map.getView().getCenter()` |
| [10:41:26] | <symbioquine[m]> | > |
| [10:41:26] | <symbioquine[m]> | > hmm seems like this actually returns an array not a `Point` object :-/ |
| [10:41:26] | <symbioquine[m]> | Oh, I meant using that to populate the initial WKT/GeoJSON |
| [10:41:41] | <mstenta[m]> | oh oh gotcha |
| [10:43:39] | <mstenta[m]> | well anyway - this was a bit of a tangent... i need to focus on getting the form element branch done first |
| [10:44:03] | <mstenta[m]> | symbioquine paul121 would you have any interest in taking a quick look in 15 minutes to provide thoughts on what i've done? |
| [10:44:17] | <mstenta[m]> | i'm hoping to merge this asap, but want to make sure you have a chance |
| [10:44:25] | <symbioquine[m]> | I'm up for it |
| [10:44:51] | <paul121[m]> | I won't be available for a few hours :-/ |
| [10:44:55] | <paul121[m]> | but can look after! |
| [10:45:15] | <mstenta[m]> | ok - maybe i'll do a quick pass with Morgan and then push the branch for your review paul121 |
| [10:45:29] | <mstenta[m]> | i have to take over with kids at at noon eastern |
| [10:45:59] | <mstenta[m]> | but might be able to jump in again, just hard to predict |
| [10:56:34] | <symbioquine[m]> | https://meet.jit.si/farmos-dev when you're ready :) |
| [10:57:12] | <mstenta[m]> | cool - on a call at the moment - will join as soon as it's done |
| [10:57:25] | <symbioquine[m]> | no rush |
| [11:01:14] | <mstenta[m]> | paul121: the only bit I didn't get to was the array/string return |
| [11:01:18] | <mstenta[m]> | but i think if you and i looked at that together we might be able to knock it out quick |
| [11:02:36] | <paul121[m]> | ah yea. we should decide one way or the other, pretty important. But using that validate trick should work! Just need to make sure it doesn't break the GeofieldWidget |
| [11:02:50] | <mstenta[m]> | that's what i ran into... `GeofieldWidget` broke |
| [11:03:13] | <mstenta[m]> | but might be easy to fix |
| [11:03:19] | <mstenta[m]> | with your eyes :-) |
| [11:03:35] | <paul121[m]> | oh dang. well, I believe it has some kind of method we could implement to pull out the correct value |
| [11:03:44] | <mstenta[m]> | ah ok |
| [11:03:54] | <mstenta[m]> | maybe Morgan and I can take a look |
| [11:04:03] | <mstenta[m]> | (still waiting for this call to end symbioquine ) :-) |
| [11:04:14] | <symbioquine[m]> | mstenta[m]: np |
| [11:05:25] | <symbioquine[m]> | mstenta[m]: I'll try... some of the Drupal form/render API stuff is still a second language to me |
| [12:38:29] | * elpronto[m] has joined #farmos |
| [13:32:48] | <mstenta[m]> | https://twitter.com/vordude/status/1537458665044574208 |
| [14:37:26] | <FarmerEd[m]> | I'd say it's a very niche market for those T-shirts |
| [15:26:32] | <mstenta[m]> | symbioquine: paul121 made the (obvious in hindsight) point that #edit is redundant/unnecessary. Just use farm_map instead of farm_map_input |
| [16:07:31] | <symbioquine[m]> | hmmm, interesting |
| [16:08:29] | <symbioquine[m]> | What about something like a "confirm submission" page where you want to show the same UX as the input field, but just not editable? |
| [16:08:51] | <symbioquine[m]> | How is that handled for other input elements? Is there some `#disabled` argument it should be honoring? |
| [16:09:59] | <mstenta[m]> | Hmm I guess it would depend on the situation, but `farm_map` elements take the same properties as `farm_map_input` - they just don't enable editing. So I think you could still just use `farm_map` in that case? |
| [16:10:19] | <mstenta[m]> | And have the same UX (if I understand what you mean) |
| [16:10:28] | <mstenta[m]> | (same `#behaviors` and `#map_settings`) |
| [16:11:23] | <symbioquine[m]> | They don't have the same UX though right? I thought `farm_map_input` has the option of showing the raw geometry but `farm_map` doesn't... |
| [16:11:35] | <mstenta[m]> | That's true |
| [16:12:15] | <mstenta[m]> | > Is there some #disabled argument it should be honoring? |
| [16:12:15] | <mstenta[m]> | Maybe this is the correct approach |
| [16:12:47] | <symbioquine[m]> | https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21... |
| [16:13:00] | <symbioquine[m]> | There is `#disabled` |
| [16:13:01] | <mstenta[m]> | If `#disabled` is set to `TRUE` then also disable the textfield/hidden input, and don't allow submitting changes in validation |
| [16:13:05] | <paul121[m]> | Ah yea, if you wanted to render a map and show the raw geometry, that could be nice |
| [16:13:10] | <paul121[m]> | but then it isn't an "input" right? |
| [16:13:19] | <symbioquine[m]> | It still is |
| [16:13:32] | <symbioquine[m]> | This is the same pattern as how HTML `<input>` can be disable |
| [16:13:38] | <symbioquine[m]> | s/disable/disabled/ |
| [16:13:40] | <mstenta[m]> | Well stepping back from all of this, I think you're just generally right symbioquine that we need to respect `#disabled` |
| [16:13:47] | <mstenta[m]> | Yea |
| [16:13:57] | <symbioquine[m]> | You don't just tell folks to use a `<span>` or a `<p>` just because they don't want the user to edit it. |
| [16:14:24] | <paul121[m]> | huh, there is `#disabled` too, maybe? |
| [16:14:24] | <mstenta[m]> | And if we don't, then `#disabled` won't actually disable our element |
| [16:14:31] | <symbioquine[m]> | mstenta[m]: And if we respect disabled, I'm all for not having `#edit` :) |
| [16:15:02] | <mstenta[m]> | Makes sense. I'll remove the `#edit` commit and add one that adds support for `#disabled` |
| [16:16:03] | <mstenta[m]> | This WILL also disable the edit controls - I think it would have to |
| [16:16:30] | <mstenta[m]> | So basically the same as `#edit`, functionally... but only using the core `#disabled` property |
| [16:16:33] | <symbioquine[m]> | yep |
| [16:16:36] | <mstenta[m]> | That's all around cleaner |
| [16:16:50] | <symbioquine[m]> | kind of the reverse of `#edit`, but yeah |
| [16:17:40] | <mstenta[m]> | yea :-) |
| [16:18:16] | <symbioquine[m]> | I don't understand why `FormElement` also has `#input` though... |
| [16:18:44] | <symbioquine[m]> | > `#input`: (**bool**, internal) Whether or not the element accepts input. |
| [16:19:00] | <mstenta[m]> | Maybe that means "this accepts input" generally, but `#disabled` is used more case-by-case |
| [16:19:13] | <mstenta[m]> | eg: a disabled textfield might not always be disabled but textfields always accept input |
| [16:19:23] | <symbioquine[m]> | ah |
| [16:19:25] | <paul121[m]> | I can't find the equivalent of this page for D8+, but it is quite nice... https://api.drupal.org/api/drupal/developer%21topics%21forms_api_referen... |
| [16:19:26] | <mstenta[m]> | can't think of an opposite example |
| [16:19:37] | <mstenta[m]> | Yea I miss that reference in D8+ :-) |
| [16:19:48] | <paul121[m]> | doesn't exist?? |
| [16:20:01] | <mstenta[m]> | Haven't seen it anywhere |
| [16:26:19] | <mstenta[m]> | > If `#disabled` is set to `TRUE` then also disable the textfield/hidden input, and don't allow submitting changes in validation |
| [16:26:19] | <mstenta[m]> | oh actually looks like Drupal handles this itself - we don't need extra validation |
| [16:26:41] | <symbioquine[m]> | ah, cool |
| [16:27:01] | <mstenta[m]> | it doesn't throw an error - it just doesn't use the overridden value |
| [16:27:04] | <mstenta[m]> | which is perfect |
| [16:27:11] | <symbioquine[m]> | cool |
| [16:27:25] | <mstenta[m]> | nice simple commit :-) |
| [16:27:30] | <mstenta[m]> | will share a link shortly... |
| [16:31:25] | <mstenta[m]> | https://github.com/mstenta/farmOS/commit/bf49a1d3516ce1fb47aa03a987577c4... |
| [16:32:32] | <mstenta[m]> | Alright... last bit is the string/array thing... paul121 and I looked at it together but the fix wasn't obvious. I think we came to the conclusion that the `password_confirm` element is not a great example to work from, because it's ONLY a form element... not used in a Field API widget. So the approach it takes may not translate to our case. |
| [16:35:03] | <symbioquine[m]> | <mstenta[m]> "Maybe that means "this accepts..." <- I think it is used [here in `FormBuilder.php`](https://github.com/drupal/drupal/blob/515d10367bbe5cc158153a90e7960f92c2...) |
| [16:40:08] | <paul121[m]> | <mstenta[m]> "Alright... last bit is the..." <- just thinking....... our current `GeofieldWidget` uses `value` in those places because *it was creating a `value` element in the form before*.... we've now pulled this piece out into `farm_map_input`.... |
| [16:40:42] | <paul121[m]> | doesn't solve this issue but might help understand why that is there |
| [16:42:16] | <mstenta[m]> | ah hmm |
| [16:42:36] | <mstenta[m]> | could we... move `value` to the root `$element`? |
| [16:42:44] | <mstenta[m]> | and somehow stick `farm_map` in too? |
| [16:44:41] | <mstenta[m]> | (thinking outside the box - pun intended) |
| [16:45:15] | <mstenta[m]> | i gotta sign off for the evening... |
| [16:50:34] | <paul121[m]> | yea that is the crux of this issue, we're so close :-/ |
| [18:14:40] | <paul121[m]> | really weird, if you remove both `#tree` and `#input` from the form element it works. even in GeofieldWidget |
| [18:14:56] | <paul121[m]> | but then it returns an empty array `[]` when no data is submitted |
| [18:15:01] | <paul121[m]> | don't fully understand |