| [11:49:33] | * MarcosCarballal[ has joined #farmos |
| [11:49:33] | <MarcosCarballal[> | Hey all, we are looking at using WebForms module for to achieve the level of customization that we are looking for. It looks promising from our use-case, but I wanted to ask if anyone had any experience with the module. We are specifically running into a blocker that we don't seem to be able to use the farmOS map within a WebForm. |
| [11:49:38] | <MarcosCarballal[> | s/from/for/ |
| [11:52:33] | <mstenta[m]> | Hi Marcos Carballal: what kind of customization are you looking for that the Webform module will provide? |
| [11:53:30] | <mstenta[m]> | That module provides a lot of nice flexibility, but it is a rather large dependency. We've avoided adding it to farmOS in the past because most of what we need can be accomplished without it. |
| [11:55:10] | <mstenta[m]> | In most cases simply coding a form using Drupal's Form API provides even more flexibility without the added considerations of Webform |
| [11:55:14] | <mstenta[m]> | But it depends what you need :-) |
| [11:55:42] | <MarcosCarballal[> | I would say there are a few things that we are looking for that we don't quite get out of the box with farmOS. |
| [11:55:42] | <MarcosCarballal[> | * Several different save buttons that redirect to different parts of the site. |
| [11:55:42] | <MarcosCarballal[> | * Conditional visibility (Some fields don't show up unless other fields are populated) |
| [11:55:42] | <MarcosCarballal[> | * Custom CSS/JS that can be local to page or applied to many different pages (I think we could do this without WebForms) |
| [11:56:17] | <mstenta[m]> | Ok yea all of those things can be achieved with Drupal Form API |
| [11:56:47] | <mstenta[m]> | I would recommend that direction over Webform honestly |
| [11:56:58] | <mstenta[m]> | Check out the Examples module |
| [11:57:00] | <mstenta[m]> | If you haven't already |
| [11:57:13] | <mstenta[m]> | https://www.drupal.org/project/examples/ |
| [11:58:15] | <mstenta[m]> | Webform uses Drupal Form API I underneath, so everything you can do with Webform you can do yourself in a custom form. Without all the overhead |
| [12:00:54] | <MarcosCarballal[> | We tried this and had limited amounts of success with the Drupal Form API. I ran into quite a few crashes while trying to develop that way. Not sure what I was doing wrong. |
| [12:00:54] | <MarcosCarballal[> | I will keep looking into it. |
| [12:04:30] | <mstenta[m]> | The reality is, Webform might get you part of the way towards your goal, but ultimately it is built on Form API too - and you will definitely run into the limitations of Webform and end up writing some Form API code either way (just my gut) |
| [12:04:59] | <mstenta[m]> | I think you'll end up hamstrung by Webform more than anything |
| [12:05:19] | <MarcosCarballal[> | You're probably right. Do you have any suggestions on learning how to use the Form API and understanding how it is organized? |
| [12:05:49] | <mstenta[m]> | This might help: https://www.drupal.org/docs/drupal-apis/form-api/introduction-to-form-api |
| [12:06:00] | <mstenta[m]> | Along with the Examples module |
| [12:06:17] | <mstenta[m]> | Specifically these sub-modules: https://git.drupalcode.org/project/examples/-/tree/3.x/modules/form_api_... |
| [12:06:54] | <MarcosCarballal[> | Thanks Mike! I swear these resources hide from me :). |
| [12:07:13] | <mstenta[m]> | Haha yea knowing what to search for is half the battle ;-) |
| [12:08:11] | <mstenta[m]> | I would *almost* suggest building on top of farmOS's "Quick Form" API... which itself is just a thin layer on top of Drupal's Form API... |
| [12:08:36] | <mstenta[m]> | https://farmos.org/development/module/quick/ |
| [12:10:27] | <mstenta[m]> | You basically extend the farmOS `QuickFormBase` class, and it provides some little conveniences (eg: automatically creates menu router item and a new link under a Quick Forms menu item) |
| [12:11:00] | <mstenta[m]> | As well as some PHP traits with helper methods so you can do things like `$this->createAsset($values)` |
| [12:11:49] | <mstenta[m]> | And automatically relates assets/logs to the quick form that created them, for added context in the future |
| [12:17:47] | <MarcosCarballal[> | Right, I remember Zane was playing around with that. So to clarify, since `QuickFormBase` extends `FormBase`, we won't run into the same limitations because we can interact with it the same way we would any other `FormBase` class. |
| [12:17:47] | <MarcosCarballal[> | One quick question. `getFormId()`, the method on `FormBase`, is a custom string that we define? If so, where do we expect to reference this value? In the routing file? Sorry, I know that this is a Drupal specific question and not FarmOS specific. |
| [12:18:11] | <mstenta[m]> | Correct - it's basically Form API + a bit of farmOS sugar |
| [12:18:31] | <mstenta[m]> | `getFormId()` just returns a custom string yet. it should be unique among all forms in Drupal |
| [12:18:50] | <mstenta[m]> | you won't really use it much anywhere yourself |
| [12:19:01] | <mstenta[m]> | but it allows other modules to "form alter" your form |
| [12:19:17] | <mstenta[m]> | https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Form%21fo... |
| [12:20:10] | <mstenta[m]> | eg:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/b9692650b1...) |
| [12:20:13] | <MarcosCarballal[> | Gotcha, so the connection between path and form is as it is here https://git.drupalcode.org/project/examples/-/blob/3.x/modules/form_api_..., and has nothing to do with getFormID() |
| [12:20:32] | <mstenta[m]> | correct |
| [12:21:02] | <mstenta[m]> | (note: with farmOS Quick Forms, the routing is taken care of for you - so you don't need the YML file... just a PHP class that extends `QuickFormBase`) |
| [12:21:38] | <mstenta[m]> | (but it wouldn't hurt to experiment with raw Form API a bit to get the hang of that and understand what it's doing either way... and maybe you won't need the extra stuff that Quick Forms provide... i'm not sure) |
| [12:24:31] | <MarcosCarballal[> | Okay, thank you! I am starting to learn that there seem to be a million ways to achieve the same thing in FarmOS. |
| [12:24:32] | <MarcosCarballal[> | The one thing that I was able to do in Webforms that I couldn't for the life of me figure out how to do with FormAPI is the multiple buttons with the different redirection points. Would you have any insights there? |
| [12:24:44] | <mstenta[m]> | That's for sure! (lots of ways to do things) |
| [12:24:56] | <mstenta[m]> | Yes! Let me see if I can find an example to point to... |
| [12:26:09] | <mstenta[m]> | First, what do you mean by "redirection points"? A Drupal Form basically has a concept of a "submit" button, which will cause the form validate and submit methods to run. This is where all your form submission logic will go, normally. But it's also possible to have *other* buttons, which cause *other* methods to run... |
| [12:26:30] | <mstenta[m]> | Do you want logic to run when the button is clicked? Or just redirect somewhere? Or both? |
| [12:27:03] | <mstenta[m]> | (oh just noticing there's a "multi step form" example in the examples module!) |
| [12:27:08] | <MarcosCarballal[> | mstenta[m]: Other buttons with other methods. Well, I don't necessarily want different saving/validation logic, I just want to allow the user option to "Save and continue to X form" or "Save and go Home" |
| [12:27:23] | <mstenta[m]> | Ah ok |
| [12:28:13] | <mstenta[m]> | So... a simple way to do that is: at the end of your submit method, check which button was clicked, and set the form redirect accordingly |
| [12:29:12] | <MarcosCarballal[> | Gotcha, I'll try that out. |
| [12:29:25] | <mstenta[m]> | First, here's how to redirect: https://drupal.stackexchange.com/questions/5861/how-to-redirect-to-a-pag... |
| [12:29:47] | <mstenta[m]> | This might help in determining which button was clicked: https://stackoverflow.com/questions/51099212/how-to-get-triggered-button... |
| [12:32:21] | <mstenta[m]> | You also mentioned this above: |
| [12:32:21] | <mstenta[m]> | > Conditional visibility (Some fields don't show up unless other fields are populated) |
| [12:32:31] | <mstenta[m]> | For that you'll want to learn the concept of "states" in Form API |
| [12:32:32] | <mstenta[m]> | https://www.drupal.org/docs/drupal-apis/form-api/conditional-form-fields |
| [12:33:29] | <mstenta[m]> | I think there's an example of that in the Examples module too |
| [12:42:38] | <MarcosCarballal[> | Thanks Mike, I'm going to dive head first into this stuff and see if I can't make sense of it |
| [14:09:26] | <MarcosCarballal[> | Sorry, one more question. Would we need to use `QuickForm` to make use of the FarmOS map display type? Or can we import it and use it as a display type? |
| [14:48:28] | <mstenta[m]> | Good question Marcos Carballal: I'm not sure we've used the map in a custom form yet, but it's a natural next step. I was planning on it for a quick form myself... |
| [14:50:28] | <mstenta[m]> | The farm_map module basically provides a custom "element" which we then wrap into a "form widget" for use with Field API |
| [14:51:25] | <mstenta[m]> | So we are already doing that... It's just a question of whether or not it's "easy" to use outside of that or if there are any "gotchas" we need to document or iterate on |
| [14:52:23] | <mstenta[m]> | paul121 or symbioquine may chime in and say "that's easy!" - but I'll set expectations low first :-) |
| [14:53:30] | <MarcosCarballal[> | Yes, it provides a "form widget" type. My thought would be that I just need to define in the Form file somewhere `display => farmos_map_widget` or something similar. |
| [14:55:02] | <mstenta[m]> | Yep basically. You would essentially add it as a form element just like you would a checkbox or textfield |
| [14:55:03] | <MarcosCarballal[> | But I really just want to replicate the behavior of the `Land` asset form 🙂 |
| [14:55:27] | <mstenta[m]> | 'type' => 'farm_map' |
| [14:55:45] | <mstenta[m]> | Or something like that. It may just be a matter of getting all the element properties right |
| [14:55:55] | <mstenta[m]> | I'm on my phone right now so can't take a closer look |
| [14:56:10] | <MarcosCarballal[> | No problem! I've got plenty to go off of here |
| [15:49:21] | <symbioquine[m]> | <mstenta[m]> "So we are already doing that..." <- In addition to examples of how the `farm_map` element is used in farmOS core, there's also this example from my land drawing tool; https://github.com/symbioquine/farmOS_land_drawing_tool/blob/44a1fb09d34... |
| [15:50:08] | <symbioquine[m]> | If you didn't want to instantiate the map from custom JS code, you'd leave off the `data-map-instantiator` attribute and let the default JS set up the map. |
| [15:55:12] | <symbioquine[m]> | The main tricky things will be figuring out how to use the Drupal "render API" within whatever context you're in and coding up any customizations you need for the map itself. |
| [15:56:26] | <MarcosCarballal[> | Thanks! I think the customization that are needed are fairly minimal. It would be nice to be able to set the default camera lat/long and zoom based on values in our database but I am not too worried about it at the moment |
| [15:59:44] | <symbioquine[m]> | MarcosCarballal[: See https://github.com/farmOS/farmOS-map#controlling-the-zoom-level |
| [16:01:17] | <symbioquine[m]> | If you bring in the existing geometry layers in the normal way, farmOS will probably already set the map zoom to encompass the existing geometry of your farm; https://github.com/farmOS/farmOS/blob/6cca1b15afec25de05e3b36e3c1cf77933... |