Changing items metadata very frequently

[Spaceman_Spiff (Sebastian)]

@rlkoshak

And that’s what one does with a rule template too. Role templates don’t do anything on their own. You need to instantiate a rule based on a template after setting the parameters. Same as you demonstrate. The only difference is the parameters are “passed” into the rule through string substitution instead of function arguments.

@rlkoshak

And yet when there is an error I have one place to look. I have one ruleuid to know. I have one entry in settings → rules. If I had 100 it would be unmanageable.

I’m not saying instantiating a separate rule per Item is wrong by any means and that is possible today if that’s how you prefer to do it both in rules files (not Rules DSL) and through the UI.

I am saying that making it so that’s the only way is wrong. It cuts off whole avenues of ways of using OH and so far the only benefit I can see is it becomes more “pure” by one measure.

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.

---

@JustinG

They are also, however, occasionally presented with an air of authority and vehemence that misses the mark on that compromise middle ground (i.e., leaving zero indication that you consider compromise acceptable on some particular point). Not intended, I’m sure; I work very hard against the same tendency myself and occasionally miss as well (which my wife will be more than happy to verify).

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.

@JustinG

If you want to put the lie to Rich’s assessment, maybe revive the PR thread and try apologizing to Jan
and explicitly stating a willingness to work with, not against, him on getting a trial new file format going.

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.

@rlkoshak

All your concerns could have been addressed individually after a first minimal viable version was released by you, or other devs (maybe even me).

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.

@rlkoshak

And after killing it

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.