jgaehring
commented
3 years ago I'm tempted to close this or rename this issue. For one thing, I think we've come a considerable ways in actually implementing this with the /farm.json endpoint. Also, not to nitpick, but I don't think it's so much a matter of what modules are installed on the server as it is what data structures the server supports, eg, the different types of logs and assets, as well as certain taxonomy terms etc. That's what Field Kit needs to be aware of, so it can retrieve, process and send that data back and forth with the server.
Again, we've made great strides in that direction so far, and to a certain extent, it's just a matter of continuing to keep the UI defensive against such variation. There is another level we could take this to, though, where we start to programmatically generate the UI based on the schemata we get from the server, from the ground up. This is what I hope to eventually do with the Log Manager (#243), which ideally can display all fields for all logs no matter how specialized. I think this is where we'll really need to utilize more granular data type information; for instance, if a log provides a field, such as movement, that provides some sort of geographical information, Field Kit needs to be able to identify that by type to say, "Ok, this is a map geometry field, so I need to render a map to display it." That might be the most complicated example, but it will also be the case for different entity references and term references as well, where it might be required to look up additional data based on the identifier. I think this is where JSON Schema (farmOS/farmOS#243) will really pay off, so this all should probably wait til then, but it's interesting to think about. Curious your thoughts, @mstenta.
Generally, I think this won't be a huge issue with individual Field Modules, which I think will tend to specialize in particular types of logs and assets, and so will be safer in making certain assumptions, but it could be helpful to offer some smart components to Field Modules that are able to parse the type of UI needed based on the available schema.
mstenta
See comment here: https://github.com/farmOS/farmOS-client/pull/188#issuecomment-482125734
farmOS allows users to specify which modules they want to turn on in their farmOS instance. This affects what asset types, log types, area types, fields, etc are available.
This means that the app may end up showing features that are not actually available on the server. For example: the "Equipment used" field may not be available on logs if that module is not installed. Similarly, if the "Crop" module is not installed, Planting assets and Seeding/Transplanting logs will not be available.
I propose that we think through some mechanisms in the app (and in the server) for showing/hiding features based on the available modules.
The first step would be for the server to provide information about what modules are enabled - and then add logic in the app to show/hide things accordingly.