dashboards=MaterialUI, pages=antd. Admin GUI as dashboard template

1

just out of curiosity I was wondering why PSU ‘pages’ are created with antd, whist the dashboards are material UI. I’m guessing so you can create pages directly in the admin GUI and retain the same look and feel is the only real reason.

I’d like to apply the antd framework to PSU and saw this experimental tool
GitHub - ironmansoftware/ud-factory: Tools for creating custom components and frameworks for PowerShell Universal. but think that there is still some way to go to implement this.

what I would love to have is the PSU admin gui as a template for my dashboard - it’s perfect for our usecase :wink:

2

It’s mostly history as to why there are two.

Universal Dashboard started out with Materialize (another framework) and when v3 was released, it moved to Material-UI. This was a significant rewrite.

Universal Automation started out with Ant Design for the admin console.

When the decision was made to merge them, it didn’t make sense to completely rewrite the UD dashboard framework (again) or the UA Admin Console.

The ud-factory project was a test to see if it was possible but is far from complete.

I’d honestly love if we used AntD for UD since it would help simplify development and give it a consistent look.

We do have some plans to begin to simplify things but it won’t replace MUI with AntD: Reduce Complexity of Universal Dashboard · Issue #554 · ironmansoftware/issues · GitHub

One thing I regret a bit is making the PowerShell interface so deeply tied to MUI. If it was a bit more generic, I think it would make sense to provide skins based on different UI frameworks without changing the PowerShell commands.

The reason pages are the way they are is because they are really just an extension of the admin console. This makes it much easier to move quickly developing features and you get the consistent look of AntD. The reason we started down the pages route was that developing a drag and drop designer for UD is difficult. Creating something that effectively reads and generates PowerShell is difficult. That said, I hope to eventually support putting UD components into pages.

This would give you the freedom to create complex components with PowerShell script but insert them into the page using the designer. Once we merge the react apps together, this will be possible.

1 Like
3

thanks for the reply, I cant imagine the amount of time and effort you have put in to get where we are today. From my humble point of view we have two scenarios that we use ‘getters’ where we get data - usually from multiple sources which we then assemble into a single view, so UD components are perfect for this. And ‘setters’ where we update some object (AD user, database, file etc etc) which are normally simple datatypes and pages are perfect for these as its quick to build a page with a form which has a consistent view.