Requiring Fields for commands

Continuing the discussion from New Hub Release 2.0:

@bravenel/@patrick
Can this be done with custom commands as well?
If yes, please provide code template.

Thanks,
Stephan

Any update on this guys?
I would love to add required fields and drop downs to my commands...just need to know how.

This was intended for documentation but slipped...

The command definition in drivers allows now for an optional 3 map to be passed into commands

Original code:
command "testEnum", ["Enum"]

resulted in this:
image

with 2.0 we added support for defining a few things:
command "testEnum", [[name:"Testing Enum", type: "ENUM", description: "Pick an option", constraints: ["one","two","three"] ] ]

will result in this:
image

What has happened is we have expanded the 2nd parameter to command to allow 4 elements in the map, name, type, description and constraints.

Name is the value that shows up where "ENUM" used to be, directly above the input. If the name ends with an asterisk (*) it will be considered required and the input box will be red and the button will not submit without a value

Type is one of the following, STRING, NUMBER, ENUM, COLOR_MAP, or JSON_OBJECT

NUMBER will constrain it to numbers +/- and decimal

ENUM allows for the constraint to be added to the select input

COLOR_MAP invokes the color picker, which can only be one on the device screen.

Description is used for the hover over of the input field. Useful in defining what the custom command is expecting, ex. Please enter a number between 1 and 100

As for Constraints, at this point it is only used for populating ENUM values but is reserved for future use.

Couple other things to note. The ENUM list is static and cannot be updated in any way shape or form from the driver, inputs, etc.

There is no validation (other than NUMBER and * being required) on inputs, this is up to the methods to handle this properly.

This is not meant to replace the preferences area, its just a way to refine the custom commands to display name, a hover over or drop down.

7 Likes

@patrick this is an awesome addition. Any chance on making this accept/call a function to populate the constraint list? I would love to make this more dynamic versus a hard coded list. Example is the AVR drivers where the setInputSource command would be populated with the list of inputs I setup in the device which could change over time.

Unfortunately, as I stated above, it is not possible and is not planned. A hard coded list is the only option at this point.

@patrick I was hoping the constraints map would allow a key value pair but it doesn't work for me. Could this possibly be included? So the above would become where 1, 2, 3 are passed to the command function:
command "testEnum", [[name:"Testing Enum", type: "ENUM", description: "Pick an option", constraints: [1:"one",2:"two",3:"three"] ] ]

While I have you, any thought into making the constraints dynamic based on a function within the app? Back in December the answer was no but y'all have made a lot of enhancements since then.

1 Like

My dirty method:

def testEnum(string) {
	def keyPairs = [1:"one", 2:"two", 3:"three"]
	def value
	for (int i = 1; i < 4; i++) {
		value = i
		if (keyPairs[i] == string)
			break
	}
// do something with value
}

Thread necromancy but...

@bravenel Is the command metadata documented anywhere? I couldn't find it. I would love for there to be a place I can point new developers to for showing how to require and type commands.

1 Like

The official unofficial documentation is:

1 Like

Yeah, I saw it up there. I linked it in this linked post a little while back. I was just hoping for something official in the wiki that spelled out how you can pass a map or a single string and then the behavior when you do either. It would be handy to give to newcomers.

The wiki is editable... You need to create an account... but it is editable...

As such, I have submitted the documentation, with proper attribution, and it should appear when approved...

5 Likes

Awesome, perfect and thank you. You are a better supporter than I am. I hate doing documentation at work and I want to do it even less here. I really do appreciate it.