You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently a number of new features in Argus htmx have been released that are not relevant for us (Geant), most notably:
incident filter-select widget -> we have implemented our own filter widget and the offered logic by the widget assumes that the filterblob content matches Argus's default implementation, which is not the case for us
destinations page -> we currently do not use the destinations feature, and would like to hide it from our UI so to not confuse our NOC (see Allow customizing user menu #1181)
Both of these features however, are hard-coded in the templates, making it difficult to disable or customize them. I've already created a PR to make one of them optional (#1181), but have not worked on the other (that one is more involved). However, this is corncerning to me. It would be really useful to us if there could be more emphasis on the customizability/extensibility of Argus. While in the beginning of argus-htmx-frontend there was sufficient focus on customizability, I feel like this has dropped somewhat over the passed couple of months, and I was hoping if we can make this more of a priority again. Lacking certain customizability options really hampers the maintainability of our hybrid geant/argus stack.
My ideal situation is that for every (significant) new feature there is logic and documentation on how to customize the feature and/or make it optional. This could be achieved by the way the templates are strucutred, or by exposing settings, plugins, hooks or context processors. The goal would be to be able to reuse as much of the templates and logic as reasonably possible while still allowing third parties (ie: us) to add or remove features on key area's of the htmx frontend.
Now, I realize that this is an ideal, and not necessarily realistic, but a large part of it is getting the right mindset. When adding new features, we can find common patterns and slowly build towards a better developer experience for third parties to compose and customize their Argus instance.
What do you guys think? Do you share this vision/ideal? What can we (Geant) do to help you towards this goal?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Recently a number of new features in Argus htmx have been released that are not relevant for us (Geant), most notably:
Both of these features however, are hard-coded in the templates, making it difficult to disable or customize them. I've already created a PR to make one of them optional (#1181), but have not worked on the other (that one is more involved). However, this is corncerning to me. It would be really useful to us if there could be more emphasis on the customizability/extensibility of Argus. While in the beginning of
argus-htmx-frontend
there was sufficient focus on customizability, I feel like this has dropped somewhat over the passed couple of months, and I was hoping if we can make this more of a priority again. Lacking certain customizability options really hampers the maintainability of our hybrid geant/argus stack.My ideal situation is that for every (significant) new feature there is logic and documentation on how to customize the feature and/or make it optional. This could be achieved by the way the templates are strucutred, or by exposing settings, plugins, hooks or context processors. The goal would be to be able to reuse as much of the templates and logic as reasonably possible while still allowing third parties (ie: us) to add or remove features on key area's of the htmx frontend.
Now, I realize that this is an ideal, and not necessarily realistic, but a large part of it is getting the right mindset. When adding new features, we can find common patterns and slowly build towards a better developer experience for third parties to compose and customize their Argus instance.
What do you guys think? Do you share this vision/ideal? What can we (Geant) do to help you towards this goal?
Beta Was this translation helpful? Give feedback.
All reactions