Extend component powershell commands


I would like to start a discussion about the following:

I think it makes sense to have not only “New” powershell comments for each component also Get/Set/Remove/ Clear…
Currently the solution is to use the UDElement commands directly.
The idea is to make development much easier for developers experienced in Powershell but not in web based languages like HTML or JS.
In my opinion this is one problem this product is solving.


Get/Set/Clear/Remove UDTextbox

This discussion is open for all :wink:


In some cases it is quite easy to manage the right attribute but in some its always in combination with some doc search.

I feel like adding separate Get, Set, Remove and Clear for each component would be a long process, and make it less userfriendly, quadruple the amout of cmdlets / functions in the module.

What i’d like to personally see, is documentation of what each of the Get-UDElement, Set-UDElements, Clear-UDElement and Remove-UDElement does to the relevant component. IE which attributes are passed with Get, which attributes are settable with Set.


I second this one. Manipulating existing components is something I’ve found to be more complicated than most other things thus far.


Totally agree on your point of multiply the amount of commands.
But still think for an pure Powershell user it is a lot more user friendly because it totally fits the “normal way other powershell modules” are working.
Having corresponding commands foreach noun (e.g. AdUser) - New/Set/Remove …

PS: see also a need for attribute doc for all components - currently I have to search for other code snippets and find the right attribute …


Simple solution: add alias for all the commands, to point to the relevant udelement commands.
The dokumentation could prove quite useful.

Personally, i convert the $data to json and log it to a file. Primitive but effective.

I’ve had dreams of how to make this better.

The issue is that sometimes the cmdlets dont match the hashtables that are returned and then that doesn’t match what the react component is sending\expecting. There are a lot of consistency issues in here that need to be resolved.

Here’s a couple ideas I’ve had when thinking through this same problem. It would be really cool if components would return classes that had properties for the things you can set. So New-UDButton would return something like

class UDButton {
     # etc....

Then we could document the classes and you can just do a Get-Member to see what properties are available.

Next, instead of having cmdlets for the various actions, you would instead use a special scope for accessing components in your dashboard. If you had a button with the Id “btnHello”, you could access the it like this:

$Component:btnHello.Text = "Say Goodbye"

if ($Component:txtMyTextBox.Text -eq 'ThePassword') {
      Show-UDToast "That's the password"

This would make it similar to WinForms and a little easier to grok. We might even be able to get rid of the special scope and just inject variables at runtime but sometimes that gets a little tricky.

But wouldn’t this look nice?

$btnHello.Text = "Say Goodbye"

if ($txtMyTextBox.Text -eq 'ThePassword') {
      Show-UDToast "That's the password"

Just some day dreaming. There isn’t an easy answer to this and it will be a lot of work either way to both make the controls consistent and then figure out a way to make then easier to discover.

Nice dream :wink:

To sum your answer up … You dont want to have separate commands foreach component.
With this the current consistency problem can be solved too … And you do not need to know any attribute in an update case (Set) because the command Set-… is showing the right parameters …

A Get-UDButton without an ID can for example return all buttons by using Get-UDElement and filter by type (should work - just came out of my mind as I am currently in an London hotel attending the Ignite Tour)

I’d rather not have separate commands, no. I’d rather solve the consistency and then document the components and\or make them self documenting with classes.

Get-UDButton to return all buttons is a neat idea.

I see … Thanks for this discussion :slight_smile:

So @adam , what is stopping you from implementing PowerShell Classes? I’ve used them pretty successfully in the past, and I’d be happy to contribute where I can.

1 Like