| [21:15:24] | * symbioquine has joined #farmos |
| [21:17:16] | * symbioquine__ has quit (Ping timeout: 265 seconds) |
| [00:30:42] | * JustTB has quit (Ping timeout: 258 seconds) |
| [01:36:05] | * wimpertier[m] has joined #farmos |
| [04:33:04] | * JustTB has joined #farmos |
| [04:38:26] | * JustTB has quit (Quit: Leaving.) |
| [05:01:16] | * JustTB has joined #farmos |
| [06:19:15] | * svenn has joined #farmos |
| [11:57:14] | * JustTB has quit (Ping timeout: 240 seconds) |
| [12:13:17] | * farmBOT has joined #farmos |
| [12:13:44] | * JustTB has joined #farmos |
| [12:31:00] | * symbioquine has quit (Quit: Leaving) |
| [13:03:44] | <generalredneck[m> | Posting this event here as yall may be interested in it. https://twitter.com/decoupleddays |
| [13:04:23] | <mstenta[m]> | Thanks generalredneck ! Definitely need to get this on my calendar |
| [13:04:37] | <generalredneck[m> | Call for Papers is open |
| [13:04:59] | <mstenta[m]> | Great - I think jgaehring was looking into that already! :-) |
| [13:06:30] | <jgaehring[m]> | oh yea! |
| [13:09:02] | <generalredneck[m> | one of my co-workers helped get this thing rolling each year so he keeps us up to date. Jeff Tomlinson |
| [13:11:17] | <mstenta[m]> | oh cool! |
| [13:12:06] | <mstenta[m]> | Pedro Cambra (@pcambra on d.o) actually turned us on to this the other day! |
| [13:12:38] | <mstenta[m]> | Seems like a really good place to show what we're doing with Field Kit and get feedback from the larger community |
| [13:13:53] | <generalredneck[m> | yeah and it's a sizable camp |
| [13:15:24] | <generalredneck[m> | I typically go to MidCamp in Chicago too as they are a pretty good camp but my baby's due date didn't let me this year. If you want somethign small but probably more along yalls users (education and farming community) there's Drupal Corn |
| [13:15:41] | <generalredneck[m> | they usually only get 100-150 attendees though |
| [13:18:08] | * JustTB has quit (Ping timeout: 265 seconds) |
| [13:19:24] | <mstenta[m]> | I've heard of Drupal Corn! |
| [13:19:26] | <mstenta[m]> | haha |
| [13:19:31] | <mstenta[m]> | seems like a great fit |
| [13:19:54] | <jgaehring[m]> | am I reading that right? Drupal Corn? |
| [13:20:15] | <mstenta[m]> | yup |
| [13:20:19] | <mstenta[m]> | https://2019.drupalcorn.org/ |
| [13:22:33] | <generalredneck[m> | yeah I had the same reaction first time... someone totally typoed DrupalCon :P |
| [13:22:58] | <generalredneck[m> | Google will tell you "Did you Mean DrupalCon" too which doesn't help :P |
| [13:23:42] | <mstenta[m]> | haha |
| [13:23:55] | <generalredneck[m> | Used to be in Iowa City (kinda in the sticks) now it's in Des Moines which is a small step up... but Meredith Publishing is the biggest Drupal userbase around the area minus the colleges |
| [13:24:46] | <mstenta[m]> | neat |
| [13:25:04] | <mstenta[m]> | Maybe eventually farmOS will take over as the biggest Drupal userbase ;-) |
| [13:25:25] | <mstenta[m]> | #2020goals |
| [13:26:28] | <jgaehring[m]> | hahaha |
| [13:27:24] | <mstenta[m]> | Then we can make the "DrupalCorn" name more literal ;-) |
| [13:27:30] | <mstenta[m]> | haha |
| [13:27:55] | <generalredneck[m> | ACTION uploaded an image: image.png (149KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/osqyTRQroSKcqUqY... > |
| [13:28:35] | <generalredneck[m> | ACTION uploaded an image: image.png (124KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/OcTvmlCRhoiFCSsI... > |
| [13:28:45] | <generalredneck[m> | Trying to help... :P |
| [13:29:35] | <mstenta[m]> | Awesome! |
| [13:29:51] | <generalredneck[m> | That would be for Agriculture.com FYI |
| [13:30:03] | <generalredneck[m> | Successful Farming magazine |
| [13:30:07] | <mstenta[m]> | Wow so cool |
| [13:30:16] | <jgaehring[m]> | oh super cool! |
| [13:32:14] | * JustTB has joined #farmos |
| [13:37:54] | <mstenta[m]> | One thing I'm interested in thinking through with you @jgaehring:matrix.org is the possibility of some field modules being available directly in the farmOS server UI |
| [13:38:24] | <generalredneck[m> | ☝️would love that |
| [13:38:51] | <mstenta[m]> | Reasoning: one of the big benefits of the field module work is that it provides a way for forms to be built in JS, instead of needing to know Drupal |
| [13:39:03] | <mstenta[m]> | We've talked about converting the existing Quick Forms to Field Modules... |
| [13:39:32] | <mstenta[m]> | But, some of them (and potentially more in the future) may not fit the "in the field" description - and are more useful in the office |
| [13:39:56] | <mstenta[m]> | Now... whether or not it makes sense to use the same framework, I'm not sure... maybe we just need more general support for Vue.js in farmOS/Drupal frontend |
| [13:40:03] | <mstenta[m]> | But I'd love to think that through in more detail soon |
| [13:40:31] | <jgaehring[m]> | > One thing I'm interested in thinking through with you @jgaehring:matrix.org is the possibility of some field modules being available directly in the farmOS server UI |
| [13:40:31] | <jgaehring[m]> | Oh yea, I've been thinking about that more with some of the proposed work we've been discussing lately (eg, generating input mixes from farmOS) |
| [13:40:42] | <generalredneck[m> | See if you decoupled you wouldn' thave to pull anything into the Drupal UI... and leave the Drupal side of things for when someone has to configure stuff |
| [13:40:43] | <mstenta[m]> | If you recall, we've also discussed hosting Field Kit as a PWA directly in farmOS too, with the ability to toggle it open/closed |
| [13:41:12] | <mstenta[m]> | Yea - I mean... going further decoupled in farmOS 2.x is really worth considerring |
| [13:41:25] | <jgaehring[m]> | > Now... whether or not it makes sense to use the same framework, I'm not sure... maybe we just need more general support for Vue.js in farmOS/Drupal frontend |
| [13:41:25] | <jgaehring[m]> | oh interesting, yea, that could definitely be worth exploring |
| [13:41:26] | <mstenta[m]> | Still - using Views is a big win for the Drupal side, IMO |
| [13:41:46] | <generalredneck[m> | yeah but you can pull in the views via JSON |
| [13:41:54] | <mstenta[m]> | true true |
| [13:42:12] | <mstenta[m]> | We do make use of Views exposed filters, CSV exports, etc a LOT too |
| [13:42:26] | <mstenta[m]> | Probably doesn't make sense to rebuild all of that |
| [13:42:30] | <generalredneck[m> | and there are far better charting technologies out there in straight JS than ones that have a "drupal" version. |
| [13:42:37] | <mstenta[m]> | So some stuff still makes sense to keep in the Drupal UI maybe |
| [13:42:51] | <mstenta[m]> | Yes yes! We would benefit a lot from all that |
| [13:42:57] | <generalredneck[m> | yes... no... you can keep the functionality... |
| [13:43:06] | <mstenta[m]> | Perhaps a "progressively decoupled" approach |
| [13:43:12] | <generalredneck[m> | and just take advantage of import and what not... |
| [13:43:38] | <generalredneck[m> | I say that... you are right... the wizard part of that is useful |
| [13:43:46] | <mstenta[m]> | So the real question becomes where do we draw the lines and how do we make the JS code as reusable as possible to share between Field Kit and farmOS UI? |
| [13:44:06] | <mstenta[m]> | eg reusable component |
| [13:44:09] | <mstenta[m]> | * eg reusable components |
| [13:44:46] | <mstenta[m]> | but if we could share more of the field kit/field module architecture, that might be really useful |
| [13:45:15] | <mstenta[m]> | it would allow a JS developer to build features that could be either a field module, or a farmOS module, or both |
| [13:45:22] | <mstenta[m]> | using the same basic code |
| [13:45:24] | <mstenta[m]> | maybe? |
| [13:45:37] | <mstenta[m]> | lots of details to think about :-) |
| [13:46:28] | <jgaehring[m]> | I think I like the idea of there always being a "raw" Drupal-y interface that power users, admins or (maybe) farmOS Cert'd Technicians™ can access, but have a totally decoupled UI facing most farmers/farm managers/workers |
| [13:47:30] | <generalredneck[m> | when we "decouple" we always leave access to the Admin interface at the very least. |
| [13:47:57] | <generalredneck[m> | just the main traffic goes to the react application url instead of /admin |
| [13:49:01] | <jgaehring[m]> | > So the real question becomes where do we draw the lines and how do we make the JS code as reusable as possible to share between Field Kit and farmOS UI? |
| [13:49:02] | <jgaehring[m]> | well, we started off structuring things pretty modularly in Field Kit, and how we do that has evolved, but we still have the networking logic pretty well self contained, and as we build out the component library more, that gives us plenty of opportunities to add Field Kit UI elements into farmOS incrementally |
| [13:49:11] | <jgaehring[m]> | > just the main traffic goes to the react application url instead of /admin |
| [13:49:12] | <jgaehring[m]> | ah, nice, that makes sense |
| [13:49:15] | <generalredneck[m> | and we add a link to the user login if they have a permission (since that's an api call you can make), and it will take them to the "drupal side" of things |
| [13:51:32] | <generalredneck[m> | another strategy that people do is host the decoupled app on the main domain (www for example) and then have the drupal side on admin.website.com or api.website.com |
| [13:51:40] | <generalredneck[m> | but then you have the whole CORS thing to deal with :P |
| [13:51:55] | <mstenta[m]> | ah yea that's basically what we're doing now with https://farmOS.app |
| [13:52:33] | <mstenta[m]> | farmOS.app is the decoupled frontend, and each individual farmOS server has its own URL |
| [13:52:56] | <mstenta[m]> | but the focus has been on Field Kit being for "in the field" use |
| [13:53:21] | <mstenta[m]> | as we move forward, I think there's benefit to building some forms for "in the office" work using the same framework, if possible |
| [13:53:26] | <jgaehring[m]> | ACTION uploaded an image: image.png (67KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/ARhnvAazPyQzOykW... > |
| [13:53:32] | <mstenta[m]> | hahaha |
| [13:54:02] | <mstenta[m]> | omg yea we spent a lot of time making that work |
| [13:54:07] | <mstenta[m]> | (still are haha) |
| [13:54:07] | <generalredneck[m> | there's no reason you can't have both farmos.app and a vue.js frontend at index on the drupal site too that share a library |
| [13:54:37] | <mstenta[m]> | that's true |
| [13:54:55] | <mstenta[m]> | that's sort of what i was thinking actually... |
| [13:55:03] | <generalredneck[m> | the difference is you would do some detection of where you are and decide to expose the drupally bits :P |
| [13:55:12] | <mstenta[m]> | and maybe they could actually be the same codebase... and we just differentiate which field modules are enabled |
| [13:55:21] | <generalredneck[m> | that too |
| [13:55:35] | <mstenta[m]> | one thought i had too: we could just display Drupal UI in the Vue.js app perhaps |
| [13:55:42] | <mstenta[m]> | maybe |
| [13:56:30] | <mstenta[m]> | like: even though it's intended to be used as an SPA, we could still use it as a wrapper in the farmOS Drupal theme |
| [13:56:57] | <generalredneck[m> | bah supid riot |
| [13:56:57] | <mstenta[m]> | so you load a page and it shows the Drupal UI inside the Field Kit wrapper |
| [13:57:00] | <mstenta[m]> | there are issues with that idea... but something to think about |
| [13:57:10] | <mstenta[m]> | yea it's going super slow right now :-( |
| [13:57:13] | <mstenta[m]> | my messages are lagging too |
| [13:57:38] | <generalredneck[m> | so... getting component HTML is easier via D8 than it is in D7 |
| [13:57:41] | <generalredneck[m> | jsut FYI |
| [13:58:08] | <mstenta[m]> | ah yea! right... there are some good options available |
| [13:58:26] | <mstenta[m]> | so it could be an SPA |
| [13:58:37] | <mstenta[m]> | that loads blocks into it's layout via AJAX |
| [14:06:47] | <generalredneck[m> | https://www.drupal.org/docs/8/modules/decoupled-blocks-vuejs |
| [14:07:12] | <mstenta[m]> | omg i love it |
| [14:07:32] | <mstenta[m]> | never ceases to amaze me how much the Drupal community has done |
| [14:07:54] | <mstenta[m]> | so... https://www.drupal.org/project/pdb |
| [14:08:14] | <mstenta[m]> | wow. |
| [14:08:23] | <mstenta[m]> | > This module is a javascript-framework-agnostic, progressive decoupling tool to allow custom blocks to be written by front end developers in the javascript framework of their choice, without needing to know any Drupal API's. It keeps individual components encapsulated in their own directories containing all the css, js, and template assets necessary for them to work, and using an info.yml file to declare these components |
| [14:08:23] | <mstenta[m]> | and their framework dependencies to Drupal. |
| [14:08:34] | <mstenta[m]> | 😐 |
| [14:08:49] | <mstenta[m]> | 🙌 |
| [14:09:33] | <generalredneck[m> | yeah I can't vouche for it. cause I still work in D7 mostly. I could get with some of the build team and ask some questions but I by no means am an expert |
| [14:09:51] | <mstenta[m]> | jgaehring: perhaps this could be how we serve field modules to field kit in Drupal 8 |
| [14:10:25] | <mstenta[m]> | as well as for farmOS server UI components |
| [14:12:02] | <mstenta[m]> | > yeah i can't vouche for it. |
| [14:12:02] | <mstenta[m]> | yea, looking closer... not very well maintained |
| [14:12:18] | <mstenta[m]> | but if it's simple that might not matter |
| [14:12:23] | <mstenta[m]> | only an alpha release currently |
| [14:12:40] | <jgaehring[m]> | oh interesting... trying to grok |
| [14:12:58] | <mstenta[m]> | but also: this might not be something we need a contrib module to do... it's probably a relatively simple thing to roll our own |
| [14:13:02] | <mstenta[m]> | if it makes sense to do that... |
| [14:14:20] | <generalredneck[m> | Honestly, for the most of the functionality you will want to stick to standard Vue... grab the info via rest... and go to town... this would be for something you can't/don't want to replicate functionality wise that Drupal supplies from best I can understand |
| [14:14:54] | <mstenta[m]> | right |
| [14:15:01] | <mstenta[m]> | true |
| [14:15:22] | <mstenta[m]> | cool! well every day i get more excited for d8 :-) |
| [14:15:52] | <mstenta[m]> | i've been very fastidious about adding contrib modules to farmOS in D7... to keep the barrier to upgrade low |
| [14:16:48] | <mstenta[m]> | it will be fun to consider pulling in some of the new stuff that's been developing out there :-) |
| [14:17:34] | <generalredneck[m> | yeah... I have mixed feelings... doing a site I pull in as much contrib as possible because it's a chance to "give back" which is a company value at 4K |
| [14:18:15] | <generalredneck[m> | but then I rarely have to think of... Well what's this gonna look like when we upgrade it... because when someone does an upgrade they want to clean house anyway |
| [14:19:00] | <generalredneck[m> | so I can see both sides of the fence on using contrib modules. |
| [14:19:26] | <mstenta[m]> | Yea agreed |
| [14:19:46] | <mstenta[m]> | And with sites they are all unique with lots of different requirements |
| [14:20:17] | <generalredneck[m> | and if I look at it with a crappy point of view... it means more work for me which == more $ :P |
| [14:20:21] | <generalredneck[m> | job security! |
| [14:20:39] | <mstenta[m]> | Haha also true |
| [14:21:06] | <generalredneck[m> | with you... not so much == less money because more dev |
| [14:21:30] | <mstenta[m]> | Yea exactly - my main equation these days is "more code == more to maintain" |
| [14:22:08] | <mstenta[m]> | But the distro/app vs site distinction is always exactly that difference I think |
| [14:22:29] | <mstenta[m]> | Sites are inherently complex because they are each one-of-a-kind |
| [14:22:59] | <mstenta[m]> | (with the exception of multisite installs - but even then sometimes...) |
| [14:23:17] | <mstenta[m]> | * (with the exception of multisite installs - but even then a LOT of the time) |
| [14:33:06] | * JustTB has quit (Ping timeout: 268 seconds) |
| [14:47:41] | * JustTB has joined #farmos |
| [18:29:14] | * JustTB has quit (Ping timeout: 240 seconds) |