I think you are misunderstanding what I am suggesting and I think it’s mainly because we use instantiating in a different context. Additionally I think you are misunderstanding that I am suggesting that this should be the only way to create rules.
I’ll try again to describe what I meant:
Let’s say there is a new rule type “Parametrized Rule”. When you create it you have to describe the parameters it takes e.g. the type (string, date or even custom types), the name of the parameter and an optional description.
Parametrized Rule
doesn’t do anything by itself, you have to instantiate it to make it work. When you instantiate it you have to supply the non optional parameters and they are bound to the instance of the rule - just like a class and a class instance. The internal variables of Parameterized Rule
are bound to an instance so each instance is a rule of it’s own.
So you still have only one Parametrized Rule
and one place to look at if things go wrong but a quick and easy way to apply this rule multiple times. If you modify the Parametrized Rule
all the instances get modified, too.
In the UI you would click on the Parametrized Rule
and then see all the instances of the rule with the parameters and a +
button to add another, etc.
The main benefit is that there is a structured and fail proof mechanism of providing the rule parameters and instance specific variables. No more parsing and validating the item metadata in each rule because that’s done by the Parametrized Rule
functionality. The UI can immediately show an error message if the parameters are wrong.
The UI can provide hints and have a nice dialogue where one can enter the parameters. No more typos and no more errors in logs because of wrong metadata.
Also it would be easy to create multiple instances because one could provide a table where one could enter the parameters or select items from a dialog and create instances for them. That would be much more user friendly then tediously creating metadata for each item.
Additionally it would be very easy to get an overview for e.g. which items there is a ThresholdAlarm.
Thanks for the hint - that’s not my intention and I’ll try to pay more attention to it. If you see some posts from me again where this is the case it would be nice if you could just pm me so I can readjust.
I’m not really sure what I should apologize for. Do you feel that I have attacked him or mistreated him in any way? If so please point out because that is and has been by no means my intention.
I signaled multiple times that I would love to provide conceptual input and work together for a new file format, too. I’ve even tried to create a sample file format to get some feedback. Unfortunately I have not been taken up on that offer on working on a file format together nor have I gotten much feedback. I’m not sure that if I write it again it’ll change something.
But there has been no indication that changing the file format in a way that addresses any of my issues will be feasible in the future. There has been a clear statement that textual configuration is an advanced approach which should be “close to code” thus more or less locking the file format.
Of course I then try to improve my argument in case there is a slight chance that at least some points will be addressed.
Please stop phrasing it that way because it implies that I have some kind of decisional power over which PR gets merged and which doesn’t. I have never even written once that this PR can not or should not be merged.