Hmm perhaps it would have been better if I had written "multiple levels" instead of "infinite levels". Because you are right that infinitive levels would be a horrible user experience.
However if the grid would only offer one single level, then there are lots of properties it cannot display: originally I wanted to develop such an editor for my node-red-contrib-onvif-nodes: for example in Onvif you can specify (an array of) multiple video sources, each with its own properties. Each video source can have a resolution (which in turn has x and y values), and a video format like mp4 (which has in turn has other mp4 related properties), ...
So a widget that only offers one single level cannot solve my issue. So I have never been able to finish those nodes for NPM publishing, since I have never had time to solve this...
@BartButenaers with upgoing node you have agreed to do with me you are on position to find solutions to provide one level set of option to satisfy multi level options to set. I have some Ideas to discuss but those are in deep of the non existing thing so not yet public.
It is possible and important to have - default makes the widget to show something. Somethung which directs a route to proper configuration changes.
Even if we go totally of topic now:
Here is how I solved as similar problem (array of objects with different properties)
certainly you can go deeper and put a editable list within an editable list - if there is any need to do so
Personally I got rid of nearly all HTML and packed all jQuery stuff inside my own class/object. Mainly because I currently use the editableList a lot. This enables me to define all UI elements with a single line of code each taking care of all the other things including collecting all the data during oneditsave. My capabilities here are limited and I would be more than happy to adopt anything provided same as I'm happy the use of the core widgets.
Back to topic:
This was not intended at all. Making the list editable needs to group them (like you might do with tabs or paragraphs), sort them, hide them if necessary, name them (very difficult, humans are not known to be good in naming things). Giving the right options and tools for data input and perhaps provide some tool-tips and/or context sensitive help. As I tried to explain with my screenshots the user experience don't have to be so different and should not replace the "Big Screen".
As I tried to say and sorry it may be misunderstood perhaps due to English is not my mother's tongue the problem and idea is grounded on the problem that the amount of time invested into the config UI is not related to the actual functionality of the node itself. I appreciate the development and documentation of the UI widgets which helped me a lot. Packing them together into a schema driven dialog form system could make live easier for the developers and the user experience more consistent. And perhaps open a lot of possibilities including an editable properties bar 
(if it is useful and desired by the overall Node-RED experience) 
BTW: What is the intention of the properties panel? I find it very useful to quickly test my nodes during development if the UI produces the result that I intended to do. But for all the rest I don't have any use for it.
Which properties panel are you referring to?
The nodes:changed event tells me that something has changed but not what. It also doesn't tell me whether what has changed is actually different to what was last deployed.
It wouldn't have to be a separate function. It might just be some additional information to identify what stage things were at. Such as the initial editor load.
I've only just come across this scenario myself 
oneditprepare is fired when you open the panel. But the validation functions are run when the editor loads as well.
What I need is to be able to check the uibuilder URL. When it changes, I need to be able to make sure that the url isn't already in use. I can do that by calling an API when the validation function runs. But then I don't really need to if it is only when the editor is loading.
Also, things happen differently if you copy/paste a node. In that case, the new node gets all of the settings of the old apart from the ID. Obviously that is a problem because I can't have two uibuilder nodes with the same url. So really I need to detect that (it can happen if you import an exported node/flow from the same instance as well).
At the moment, I'm having to track both the deployed instances of uibuilder and the editor instances since people can make multiple changes or multiple additions before doing a deploy and all instances need to be unique both in the editor and when deployed.
Of course, it is possible that I'm over-thinking things but I keep hitting edge-cases that are hard to track and detect.
It tells you about what you've got selected. Being able to check a node's configuration without opening the dialog can be useful. But there's also a reason the properties are hidden by default - they aren't necessarily going to be used by everyone.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
