Question for supporters...

[jdanylko]

Sorry for the delay in responding back to everyone, but life interrupted me, put some projects on hold, and COVID infected my entire family for 3 weeks and we're now coming out of it...slowly.

Quick architectural question...

I've been toying around with restructuring the project in a better way so users can benefit from the various components and I need your input.

As you know, Tuxboard is broken into three parts: client-side, API, and library.

Let's first address the elephant in the room: the client-side.

Since there are so many front-end frameworks available, I wouldn't be able to keep up with all of them for Tuxboard which is why I'm focusing on a plain-jane TypeScript front-end. Let users create their own front-end using their own JS framework of choice.

I did want to separate the client-side from the backend and make the backend simply Nuget-able (isn't that a song?). The problem is the backend can be broken down even further containing an API and a Service library which leads me to my question...

Would users want...

1. Tuxboard.Core as one NuGet package with a Tuxboard.Api NuGet package, or...
2. Tuxboard.Core with the library and services included so you can create your own API package?

I'm trying to find the best, most fluid approach on what makes the most sense on how users would use the library.

In the next couple of weeks, I'll be getting back to the project once things in the household get back to "normal."

Thanks, JD

[papyr]

Hey @jdanylko hope you/family are doing better.

This is such a sweet surprise found it following another users who mentioned it. Before answering your question, hope you are aware that it hits the sweetspot by addressing core feature of MVC `portalized dashboardfeature directly` in an easy to embed way, yet simple and well done! Yes, separating the front end would make it more responsive, just be cautious if you get too far away from the ASP stack.. which is what most of the developers use, sadly unlike Java/Ruby there are no options. It may take some time for other developers to find your library, if its active people will invest.

1. Razor MVC with simple RxJs (or Plain JS / Typescript) with .NET core 6 would be my vote.
   • allow data updates with observables& async Pipes, dont reload the entire view/page
   • easily create and surface the chart components to user
2. Tuxboard Nuget would allows us to update to your latest from VS, plus people can come back here to contribute PR's or suggestions. But there are cases where nugets are not allowed behind the firewall and developer will need to download and add the library as an api.
3. Please Allow roles/claims as fluent option to secure data (use can use the DynamicFilters ) For e.g. Add.Widget.AddClaim("FinanceManager") then..

   modelBuilder.Filter("RestrictItemsBaseOnAccsess", 
               (IAccessRestrictedItem x, List<string> dashboardRoles) => x.AccessType == AccessType.Public
                        || roles.Any(r => r == x.AllowedRolesPremissionJsonString),
                (GlobalFilter ctx) => ctx.IdentityManager.GetCurrentIdentityRoles())

4. The developers are looking for UI driven functionality, which boils down to allowing business users to add widgets with settings like you have with ViewComponents+TagHelpers

[jdanylko]

Thanks papyr. Family is doing better.

I'm hoping this library can help with your dashboard needs. :-D

Regarding your questions,

1. While I did include 3 examples (all front-end), I wanted this repository to be solely as a back-end dashboard library. (Refer to FAQ 2).
2. Exactly. I landed on building this repository using the Tuxboard.Core into NuGet with a collection of three samples on how to use it.
3. I've done this before where I've attached a PlanId to a Widget (WidgetPlan table) and a user belongs to a Plan when they sign up. Usually, I create either a UserPlan junction table (UserId, PlanId) or add a PlanId property to the IdentityUser/ApplicationUser. Oh, and yes, you can easily do this with Roles as well. Same concept, but instead of PlanId, use RoleId. Your "WidgetRole" table would contain a RoleId and WidgetId.
4. This ability is included with this library. You need to think about what settings to include in each widget and what the user can change. The downside (is it?) to this is the Widget has to be coded as a ViewComponent and "registered" in the database. The business user wouldn't be able to "create" their own widget, but select one based on their needs.

I've FINALLY merged the feature/TypeScript branch into master so there are examples available, but there are front-end bugs. ;-)

[papyr]

If you have a chance check this out, https://docs.abp.io/en/abp/latest/UI/AspNetCore/Widgets ...

I have shared this with some friends, and they love the idea and the architecture behind your dashboard.

Because of the experience and thought you have put in, it aligns very well with real world usage especially for the types of applications/non-profits/sports teams/small companies.

I am overjoyed to see progress, hope you get some exposure out there 💯

[jdanylko]

Thank you so much for your support, @papyr.

It's getting to the point now where I see a dashboard and immediately relate it to Tuxboard and how I would integrate it (It's pretty simple with the LayoutRows). 👍

I'm trying to dedicate time to this, but I have a CMS I'm rewriting, two other side projects, a blog, and two clients so time is a bit limited (oh, and then there's the family) LOL.

The good news, though, is my CMS will be using Tuxboard on the main page so I'll be "eating my own dogfood."

I NEED to get it into NuGet soon. :-)

Thanks again

[papyr]

If you get it to point where other projects are dependent on it, then some of the active developers can support your vision.

I find that your concept/design of the dashboard, the nested widgets and settings is the most "sane". Several organizations can relate and leverage their business use cases to your design and how the metrics are visually hoisted into the portlets/widgets. Hopefully you can get others to understand and adopt it.

[fasteddys]

Hey there, kinda new to this, but its really nice, well thought out. So, I decided to try it, and I have .NET 6 running and tried this, I ran the automatic update dotnet tool install -g upgrade-assistant from here

after reading the docs there, it seemed easy and did the upgrade fine and launched very quickly, but then nothing it keeps spinning.

Am I supposed to see some sample data, how can try this out.

[jdanylko]

I have not tested this with .NET 6 yet. During my downtime, I'll be experimenting with some updates on my projects (public and private) and this will be one of those projects.

Updating to .NET 6, I'll first examine the StaticDashboard project since that is the simplest and doesn't use too much JavaScript, then the other two.

The other two, I would recommend opening up the DevTools (usually F12 in the browser) to find the JavaScript issue. If you got the spinners, this means the server-side did it's job and the JavaScript realm is now taking over. :-)

In the Wiki, I mention why I tend to stay away from the client-side portion of projects.

This project was meant to be a server-side-based dashboard library where it could be used with any client-side framework.

No offense to the JS framework experts....there's just too many of them. ;-)