Concerning 2, I’m actually not too concerned about regressions. Tests absolutely need to be performed. However, if a block hasn’t changed there should be no regressions. An unchanged block will produce the exact same code every time.
Concerning 3, I think that’s mostly organizational and how it appears in the UI. The key place where it could impact existing code is again if an existing block generates different code than before.
Concerning 5, I’m not certain that I should be the sole arbiter on what makes “good” code. I definitely have opinions but some of them can be controversial. I do have some ideas on what makes “clean” rules code but what makes for clean text code and what makes for a clean Blockly code may not be the same. We definitely should focus more on making Blockly as easy to use as possible. As long as it generates valid JS code behind the scenes I think it’s OK if that JS code is a little messy.
A few comments on the blocks:
-
Groups: Network Tools isn’t very descriptive, as a user I’d find it hard to guess what’s in that category.
-
Variables: Is there a way to set a flag on a regular old variable block to determine whether it gets recreated/reinitialized every time the rule runs or if it’s previous state is preserved? I fear about the proliferation of blocks.
-
Variables: What’s the difference between getting any old variable and a Persist variable? Maybe we don’t need that block at all?
-
Things: What the difference between the purple MyItem and the red get item item MyItem? Is this the Items category?
-
Network Tools: OK, rename this category to something else, like Core openHAB Actions or something like that. executeCommandLine isn’t a Network Tool. I’d never guess to look there for it. Maybe create a separate category for exec and add the sendHttpXRequest Actions to Network Tools would be another option.
-
Timers: I like the Timers blocks. They are very intuitive looking. Does the “Timer Name” produce a persisted variable? If not it should.
-
Notifications: It’s not clear what the difference is between the three.
-
Ephemeris: I assume it only supports the default day types of weekend, weekday, and holiday. That’s reasonable.
-
Persistence: Are the store and restore blocks working with the storeStates and restoreStates core Actions? If so they really are not Persistence actions. I expect putting them in this category would cause confusion. Based on the name of the category and the name of the blocks I’d expect the persistence database to be involved.
-
Persistence: At some point it would be nice to be able to select the persistence to select from.
-
Persistence: We are missing most of the rest of the persistence actions like historicState, sumSince, etc.
What ever makes it easier for you to implement. Unless we change blocks that are already implemented and in use the risk of breaking changes is pretty low. When the changes get merged users will get a bunch of new options, but their old Blockly stuff should work unchanged.
Also, @ysc, correct me if I’m wrong, but even if we do change the existing blocks, it won’t go and change their already existing rules. It will only apply for new rules created with that block, or modifications to rules that use that block.
So I think the risk for disruption is relatively low over all.
I don’t think so.
The whole rules documentation needs to be reorganized in my opinion. It’s horribly incomplete, only mentions the UI rules rarely, and it doesn’t really cover everything that is needed.
@Confectrician, as the docs master, what do you think? Does it make sense to add comprehensive Blockly (and eventually the other languages) to the Rules page, or should we break it up a bit sort of like the UI section? We can then have one page for Rules DSL, one for UI rules creation and usage, and maybe a separate reference page where each of the blocks are documented.
Another alternative is to have just the one Rules doc page and use the tabbed examples trick to choose and show the example for the language of choice. Since all the extra languages are now separate add-ons, I’d expect the docs for those languages to live under the add-ons docs so we’d only need to cover the OH defaults: Rules DSL, Blockly, and JavaScript.
I see good arguments for either approach. But in the mean time, @stefan.hoehn, I think just getting content written might be the primary goal. A lot of the docs we’ve written by creating a Wiki posting here on the forum to get the community involved in helping writing the docs (it doesn’t work but we try). Then we transfer those to the official docs. Since both use Markdown it’s pretty easy to transfer.
That approach might let us get the docs going before needing to make a decision on where they ultimately need to live in the official docs.
I’ve still got to write the rules part of the getting started tutorial too and this can give us a change so address both.
I’m happy to help. But I’m usually away from computers in general over the weekends. So Friday evening through Monday morning I usually won’t reply. But I try to catch up on everything I missed. If I do miss something ping me and I’ll see it.
Seconded. Though that might impact more of the existing blocks a bit more than I’ve discussed above so regression testing and clearly documenting breaking changes we can’t get around will be a priority. Also, we need a way for users with preexisting Blockly rules to regenerate their code from their blocks to use GraalVM. I’m not sure how hard or easy that might be.