The answer isn’t no, it’s just that there are lots of better ways for op too accomplish what he wanted.
You can lead the file using Java File IO libraries.
You can use execute command line and cat the file into a String.
You can use a Java Properties Object and lead the file into a Properties Object which behaves like a Map.
You can use a map file and the transform Action.
But none of these are better than the suggested solutions for op’s actual problem.
This is a completely different problem entirely from what op asked. Her wants so Strings he can reuse. You want to include code.
This is warning flag one. If you’ve gone down this route you will probably be better off using JSR223 instead of Rules DSL.
This is a good standard approach and the approach I recommend. However, it sounds like you might be taking it a bit too far for what the Rules DSL can support. You can and should separate rules into files based on function, such as lighting, weather, HVAC, etc. But if you go more fine grained then lambdas will not be much use to you. If you have lambdas that need to be used across functions, you should use Design Pattern: Separation of Behaviors instead.
No
Lambdas are stored in a global var/val. Global var/vals are scoped to the file in which they are defined.
OK, so that is all out of the way.
The Rules DSL is purposefully restricted. It limits certain options and features to provide a less complex programming environment for non-developers to learn and become productive. Among these restrictions are:
- no classes
- no data structures
- no libraries/reusable code outside of lambdas which can be used within a single .rules file
These restrictions are incredible difficult for some types of OH users to adapt to. Thankfully, through the JSR223 add-on, it is possible to write Rules using “real” programming languages including Jython, JavaScript, and Groovy. If you are unable or unwilling to adapt to the Rules DSL, you really should consider switching to one of these options.
If you want to stick with the Rules DSL, here are some Rules of Thumb you can use to apply.
- Organize your Rules by function (e.g. lighting, HVAC, etc). This will increase the likelihood that and global var/vals and lambdas will be applicable. Put another way, your lambdas and global var/vals will most likely apply to only one set of functionality. Don’t go too fine grained though as that will force you to reproduce your global var/vals in multiple files, a violation of DRY.
- Save state in Items. That is what Items are for. If you have the same if statement in lots of Rules (e.g. to calculate whether it is between certain hours of the day or day of the week), centralize that calculation into one Rule and update an Item as necessary
- Don’t be afraid to split out certain calculations and behaviors into separate Rules. For example, [Deprecated] Design Pattern: Time Of Day and Design Pattern: Separation of Behaviors. This is particularly useful to calculate state (e.g. time of day, type of day, home/away, etc) and to centralize cross cutting concerns (e.g. alerting).
- If you find yourself defining Procedures without arguments (i.e. a lambda that doesn’t return a value), consider using Rules DSL Scripts instead.
- Instead of data structures, use Groups and Items to store and organize the data.
- Use the Member of Rule trigger and the triggeringItem implicit variable to consolidate a collection of Rules that all do the same thing into a single Rule as an alternative to lambdas.
By applying these rules of thumb and design patterns, the number of cases where one needs to write a lambda should be relatively rare, which is why I said it is a red flag above.