| [02:59:18] | * jonasbits_ has joined #farmos |
| [03:09:50] | * med65[m] has quit (Ping timeout: 260 seconds) |
| [03:09:50] | * calbasi[m] has quit (Ping timeout: 260 seconds) |
| [03:09:50] | * jonasbits has quit (Ping timeout: 260 seconds) |
| [03:11:35] | * med65[m] has joined #farmos |
| [03:18:44] | * calbasi[m] has joined #farmos |
| [15:16:46] | <symbioquine[m]> | I think I got the "Assets for Taxonomy" tab mostly working... |
| [15:17:03] | <symbioquine[m]> | The main complexity now is that the fields are different for different types of assets/term combinations. |
| [15:18:02] | <symbioquine[m]> | I was trying to write a ViewsArgument plugin that would dynamically create the query on the basis of the filtered term/asset type, but that seems kinda hard... |
| [15:18:13] | <symbioquine[m]> | Is that the best path forward? Any advice? |
| [15:19:44] | <mstenta[m]> | Oh yea that is tricky huh |
| [15:21:09] | <symbioquine[m]> | I was able to implement a ViewsAccessCheck to filter out asset types which don't reference the taxonomy vocabulary in question. e.g. only show all/plant/seed asset tabs for a crop taxonomy term. |
| [15:23:27] | <mstenta[m]> | This might be hard to fully automate |
| [15:24:41] | <mstenta[m]> | > I was trying to write a ViewsArgument plugin that would dynamically create the query on the basis of the filtered term/asset type, but that seems kinda hard... |
| [15:24:41] | <mstenta[m]> | This seems like the "right" approach, I agree... but it feels like it would be pretty hard to get right |
| [15:24:51] | <mstenta[m]> | Especially when you consider base fields vs bundle fields vs config fields |
| [15:24:52] | <symbioquine[m]> | If I go forward with the views argument plugin, I think I'd need to do a left outer join between the asset table and each of the relevant taxonomy term reference fields. e.g. `asset__plant_type` or `asset__animal_type`. |
| [15:25:46] | <mstenta[m]> | Thinking backwards... I imagine you will want to render multiple Views in the frontend... one for each term reference field, essentially |
| [15:26:13] | <symbioquine[m]> | symbioquine[m]: with an `OR`'d `WHERE` statement, filtering only those assets which have the term in at least one of those joined fields. |
| [15:26:51] | <mstenta[m]> | Hmmmmmm |
| [15:27:08] | <mstenta[m]> | I'm really questioning if this is worth the effort |
| [15:27:11] | <symbioquine[m]> | mstenta[m]: So you're suggesting the approach like the "asset_or_location" plugin? |
| [15:27:26] | <mstenta[m]> | Can't you get essentially the same information by using exposed filters on asset lists? |
| [15:27:50] | <mstenta[m]> | (granted, it would be on a bundle-by-bundle basis... so you couldn't see Seed and Plant assets at the same time...) |
| [15:27:51] | <symbioquine[m]> | symbioquine[m]: Where you get the ids of all the assets as a number of separate queries, then add a simpler filter which just filters by those ids? |
| [15:28:17] | <mstenta[m]> | Hmm I don't know if that's what I was suggesting 😅 |
| [15:28:24] | <symbioquine[m]> | :) |
| [15:28:31] | <mstenta[m]> | Just trying to visualize what the desired end result would be |
| [15:28:53] | <symbioquine[m]> | Yeah |
| [15:28:57] | <mstenta[m]> | Are you imagining a single tab that shows all assets (of different types) that reference the term? |
| [15:29:32] | <symbioquine[m]> | At least for my use-case, I'm trying to get away from linking my collaborators to searches. |
| [15:29:50] | <symbioquine[m]> | I want to be able to link to the term and make it easy to navigate from there to all the assets which reference it. |
| [15:29:52] | <mstenta[m]> | > for consistency, it would probably make the most sense to add "Assets" and "Logs" tabs to term pages that show assets/logs that reference them |
| [15:29:52] | <mstenta[m]> | Sorry - I think I'm starting to backtrack on this idea hehe |
| [15:30:11] | <mstenta[m]> | Maybe it would make sense to just make a custom thing for your purposes |
| [15:30:11] | <symbioquine[m]> | e.g. see all the animals of a type or all the plants of a given crop |
| [15:30:17] | <mstenta[m]> | If it's primarily for seeds + plants |
| [15:30:56] | <symbioquine[m]> | mstenta[m]: It might... |
| [15:31:36] | <mstenta[m]> | > At least for my use-case, I'm trying to get away from linking my collaborators to searches. |
| [15:31:36] | <mstenta[m]> | Mm yea I can see the reasoning for this |
| [15:32:20] | <mstenta[m]> | A general purpose solution would probably require some complicated hacks, no matter how you slice it :-( |
| [15:32:45] | <mstenta[m]> | So it might just make sense to create a set of simple Views for each instead |
| [15:33:31] | <mstenta[m]> | I don't love the idea of maintaining those in farmOS core, personally, because like I said the same basic thing can be accomplished with existing exposed filters... so maybe it makes sense to just start out as custom... but maybe there will be a lot of demand for this in the future... we'll see |
| [15:34:31] | <mstenta[m]> | This makes me think of an old idea I had... to basically merge `animal_type`, `plant_type`, and any others that make sense, into a single unified `species` vocabulary (or something like that) |
| [15:34:52] | <mstenta[m]> | For pretty much this exact reason... (There might even be an old issue for this kicking around...) |
| [15:35:13] | <mstenta[m]> | That way it would be the same field used on all assets |
| [15:35:36] | <mstenta[m]> | But there are bigger problems with that idea I think |
| [15:37:48] | <mstenta[m]> | Ah found it haha https://www.drupal.org/project/farm/issues/2934719 |
| [15:38:02] | <mstenta[m]> | Not exactly the same... but similar |
| [15:38:03] | <symbioquine[m]> | mstenta[m]: Using the existing exposed filters right now, means that users who are looking at a planting and wants to find other/historical plantings/seeds of the same variety has to manually click back to the plants/seeds view and select the relevant filter(s). |
| [15:38:33] | <symbioquine[m]> | It's at least 4 - 5 clicks compared to 1 in farmOS 1.x |
| [15:38:35] | <mstenta[m]> | > For example, "Crop/variety" in Plantings is analogous to "Species/breed" in animals, and "Mushroom species" in mushrooms. Could they be merged together into a general "Species/breed/variety" vocabulary? I like that from a data organization standpoint, but it could also cause confusion if your terms are mixed into one vocabulary. |
| [15:38:57] | <mstenta[m]> | True true |
| [15:39:03] | <mstenta[m]> | Maybe a simple shortcut link? |
| [15:39:16] | <symbioquine[m]> | Plus it's not obvious how to "get from here to there" unless the user already has a good mental map of the farmOS data structure. |
| [15:39:19] | <mstenta[m]> | (not sure where/what) |
| [15:39:29] | <mstenta[m]> | yeaa |
| [15:40:41] | <symbioquine[m]> | Well, I'll keep playing around with it some... Maybe I can find a more elegant approach... |
| [15:44:06] | <mstenta[m]> | I wonder if you could create a menu item that essentially pre-fills the exposed filter |
| [15:44:38] | <mstenta[m]> | So `/taxonomy/term/%/assets/plant` == `/assets/plant?crop=%` |
| [15:44:58] | <mstenta[m]> | Basically show the same View but hard-code one of the filters |
| [15:45:02] | <mstenta[m]> | 🤔 |
| [15:45:36] | <mstenta[m]> | (Still would need to be two separate paths for Plant vs Seed assets though) |
| [15:54:24] | <symbioquine[m]> | Maybe I could do that in a `DeriverBase` that populates `route_parameters` for the names of the taxonomy reference field table/etc |
| [15:54:46] | <mstenta[m]> | Yea potentially |
| [15:54:54] | <symbioquine[m]> | Then extend the `Taxonomy` view argument plugin to dynamically access those paramaters from the route. |
| [15:55:01] | <mstenta[m]> | Get a list of all term reference fields, then derive paths |
| [15:55:05] | <symbioquine[m]> | yeah |
| [15:55:17] | <symbioquine[m]> | Very similar to what I'm already doing with the access check |
| [15:55:18] | <mstenta[m]> | The tricky part will be the Views argument |
| [15:55:34] | <mstenta[m]> | But maybe it can just extend from the core term reference argument plugin |
| [15:55:39] | <symbioquine[m]> | Except that shouldn't be needed once only the relevant menu items are being generated. |
| [15:55:47] | <mstenta[m]> | and dynamically set the field somehow |
| [15:56:33] | <mstenta[m]> | where this might a bit more hairy, though, is if you have multiple fields on the same asset that reference the same term...??? |
| [15:56:33] | <symbioquine[m]> | mstenta[m]: That's what I was trying to do, but it doesn't work for the "all" tab... |
| [15:56:44] | <mstenta[m]> | not sure why you'd ever need that, but it's a possible edge case |
| [15:57:13] | <mstenta[m]> | yea... the "all" tab would be the hardest i think - because it would require a bunch of `OR`s like you described... which feels like it's just asking for troublke |
| [15:58:09] | <mstenta[m]> | oh uh... another complication: |
| [15:58:21] | <mstenta[m]> | single-value vs multi-value reference fields :-/ |
| [15:58:27] | <mstenta[m]> | (maybe complicated? maybe not) |
| [15:58:57] | <mstenta[m]> | eg: `plant` assets can have multiple `plant_type` references, but `animal` assets can only have one `animal_type` |
| [15:59:24] | <mstenta[m]> | but maybe that wouldn't be hard in practice... i think they both structure their database tables the same |
| [15:59:54] | <mstenta[m]> | (separate table with one row per reference) |
| [16:01:09] | <mstenta[m]> | > where this might a bit more hairy, though, is if you have multiple fields on the same asset that reference the same term...??? |
| [16:01:09] | <mstenta[m]> | imagine an `example` asset type with two fields: `first_plant_type` and `second_plant_type` - the menu deriver would need to create two links, but they would both be for the same asset type essentially |
| [16:02:12] | <mstenta[m]> | that's doable... just need to figure out what to call the tabs... can't call them both "Example" - need to have some way to differentiate them so you knew which field was which |
| [16:02:24] | <mstenta[m]> | (veeeeery much an edge case) |
| [16:13:59] | <paul121[m]> | just something worth noting here, if you enable the `node` module, it adds a view of nodes that reference a taxonomy term on `term` pages |
| [16:14:10] | <paul121[m]> | it doesn't do this in a fancy menu tab |
| [16:14:22] | <paul121[m]> | but maybe something work at to see how it works |
| [16:14:36] | <mstenta[m]> | oh good idea! |
| [16:25:09] | <paul121[m]> | I think it creates the path for each view to be taxonomy term page itself, and it's just appended |