| [23:38:04] | * heartburn has quit (Ping timeout: 252 seconds) |
| [23:41:05] | * heartburn has joined #farmos |
| [04:30:17] | * farmBOT has joined #farmos |
| [11:41:55] | <symbioquine[m]> | > RE: https://www.drupal.org/project/farm/issues/3336484 - Reloading records back into a quick form for editing |
| [11:41:55] | <symbioquine[m]> | Tricky to do well, but could be a pretty handy feature! |
| [11:42:58] | <mstenta[m]> | I'm starting a forum topic :-) |
| [11:43:00] | <mstenta[m]> | standby |
| [11:45:48] | <mstenta[m]> | https://farmos.discourse.group/t/quick-form-api-improvements/1497 |
| [11:47:01] | <mstenta[m]> | I know most folks in here are DIYing stuff with Node Red / Asset Link / etc - so maybe the Quick Form API isn't of much interest... it is looking like I'll be spending more time on quick forms in the future myself, so these things are bubbling in my mind :-) |
| [11:48:16] | <symbioquine[m]> | Makes sense |
| [11:50:31] | <symbioquine[m]> | I see all these things as pretty complimentary. Some folks will want forms embedded in the main farmOS UI and be comfortable developing them there. Other folks will need offline forms and be more comfortable with JS/Front-end dev and turn toward Field Kit or Asset Link modules/plugins. |
| [11:51:40] | <symbioquine[m]> | Any of the three could presumably introduce abstractions for some sort of "form builder" UI that makes creating such forms a less technical endeavor. |
| [11:51:58] | <symbioquine[m]> | That's definitely the direction I'm interested in going in Asset Link. |
| [11:52:34] | <mstenta[m]> | agreed! |
| [12:00:51] | <FarmerEd[m]> | Absaloutly |
| [12:01:06] | <FarmerEd[m]> | * Absolutely |
| [12:02:57] | <FarmerEd[m]> | I must have a proper go at some quick forms, gotten a bit comfortable lately building what I need outside of farmOS. It would be great to see an enhanced API for it. |
| [12:05:01] | <FarmerEd[m]> | I imagine it would do farmOS itself no harm to have a better variety of quick forms to encourage new users along. |
| [12:24:47] | <symbioquine[m]> | <FarmerEd[m]> "I imagine it would do farmOS..." <- Yeah, I think that's one of the major selling points |
| [12:25:34] | <mstenta[m]> | yea exactly - there's a spectrum... the ultimate flexibility might be outside farmOS, but for the majority of users, they'll be limited to what is available within it |
| [12:25:44] | <symbioquine[m]> | The barrier to entry for a pre-installed quick form is probably always going to be lower than a Field Module or Asset Link Plugin |
| [12:30:43] | <FarmerEd[m]> | > Yeah, I think that's one of the major selling points |
| [12:30:43] | <FarmerEd[m]> | Or at least it would be if we produced a selection to choose from. |
| [12:31:23] | <FarmerEd[m]> | * > Yeah, I think that's one of the major selling points |
| [12:31:23] | <FarmerEd[m]> | Or at least it would be if we produced a selection to choose from. |
| [12:31:55] | <FarmerEd[m]> | Or at least it would be if we produced a selection to choose from. |
| [12:31:55] | <FarmerEd[m]> | * > Yeah, I think that's one of the major selling points |
| [12:33:24] | <FarmerEd[m]> | What's the current thinking in achieving the re-editable quick forms? An additional relationship? |
| [12:33:57] | <mstenta[m]> | I mentioned two ideas here: https://www.drupal.org/project/farm/issues/3336484 |
| [12:34:39] | <mstenta[m]> | > 1. Define an optional YML structure that can be provided alongside each quick form that "maps" data from the record (log/asset/etc) into the quick form fields. |
| [12:34:40] | <mstenta[m]> | > 2. Provide a method on the base quick form class that downstream forms can implement/override, which takes a record and loads it into the form somehow. |
| [12:35:07] | <mstenta[m]> | 2 is "easier" from the farmOS core perspective, and the most flexible probably, because it basically leaves it up to the downstream quick form code to provide PHP logic |
| [12:35:25] | <mstenta[m]> | so i feel like that is probably the more realistic one |
| [12:39:26] | <mstenta[m]> | and the thing is... we could start with (2) and then expand to (1) in the future |
| [12:39:28] | <mstenta[m]> | without breaking the API |
| [12:39:36] | <mstenta[m]> | basically just adding additional optional layers of abstraction |
| [12:39:56] | <mstenta[m]> | (eg: the (1) implementation could use it's own (2) method for the general logic) |
| [12:39:57] | <symbioquine[m]> | Would it be feasible to make a "meta quick form" implementation on top of the existing one which in turn supports other declaration formats like yml? |
| [12:40:19] | <mstenta[m]> | YES! Are you thinking like a YML config that ends up being rendered as a form? |
| [12:40:27] | <symbioquine[m]> | yep |
| [12:40:35] | <mstenta[m]> | I almost wrote that in the comments of that issue too... we had some previous discussions around a "Quick Form Builder UI" |
| [12:40:55] | <mstenta[m]> | Which would essentially create YML configs that then create forms |
| [12:40:58] | <mstenta[m]> | (I said "YES!" because I'm excited about the idea... not because it exists haha) |
| [12:41:23] | <symbioquine[m]> | I mean it doesn't really matter if it's yml/json/etc as long as it's convenient to work with programmatically |
| [12:41:29] | <mstenta[m]> | Yea |
| [12:41:56] | <mstenta[m]> | YML is already used by Drupal for config entities, which would be analogous to something like the Views UI for generating Views |
| [12:42:25] | <mstenta[m]> | So it feels like a nice next step |
| [12:42:25] | <mstenta[m]> | There's also this: https://www.drupal.org/project/webform |
| [12:42:27] | <mstenta[m]> | ... which actually IS a form builder UI that generates YML config entities :-) |
| [12:43:11] | <mstenta[m]> | But that's a bit "lower-level" (?) than "farmOS Quick Forms for generating assets/logs specifically" |
| [12:43:32] | <mstenta[m]> | nevertheless would be worth exploring to see if a farm_quick_webform integration could help in some wya |
| [13:35:58] | <paul121[m]> | Really interested in leveraging webforms, else it seems like we'll reinvent the wheel |
| [13:36:16] | <paul121[m]> | but webforms is a big big wheel that we don't entirely need to reinvent :-) |