abpframework
ABP Hybrid UI System: Re-using module UIs in different technologies
ABP natively supports 3 UI frameworks: MVC / Razor Pages, Angular and Blazor. When we create a new module, we create the UI layer for these 3 UI types separately. This increases our work significantly and decreases our motivation to create new modules (also remember the maintenance cost for all these UI layers).
As a solution, we are considering if we can reuse UI layer of one technology inside another one. For example, can we reuse the MVC UI inside Blazor and Angular applications? If we can do it, and if it makes users feel native, we can have an important advantage.
Benefits of this approach:
- Create the UI layer only once in a UI framework and reuse it in other frameworks. This will decrease the UI layer building and maintenance costs for the ABP Team.
- We think that this will increase contribution by the community since it is hard for most people to build 3 UIs for every module (maybe they are only experts in one of them).
- In that way, we can ship new modules more quickly (without waiting to complete all UI options) and complete other native UI implementations later (typically if this new module is liked and used by the people)
- It can open the road to build new UI Framework integrations for ABP Framework, like React or Vue. Introducing a new UI integration has three parts: Framework level integration (like authentication, permissions, localization, settings, ...), UI theme integration and module UI implementations. The last one takes so much time, and if we add more modules in the future, it will be harder to introduce a new UI Framework integration. In this way, at least the existing modules will be usable.
There are a few drawbacks to this approach, of course;
- Whatever we do, a hybrid used module may not make us feel completely native.
- When a developer wants to customize the UI layer of a module, they may need to deal with two or more technologies.
For the 1st problem;
- We will do our best to make it as close to native as possible.
- Most of ABP's modules (identity management, language management, tenant management, etc) are already admin-side modules. They are typically not used by end users. For these kind of modules, it is more acceptable to have minor UX differences from the main application. You know, some companies even using external systems for these kind of requirements (like Keycloak or Azure AD). In that case, these external systems' UX is totally different and not integrated into the main application.
For the 2nd problem, to be honest, nothing to do. However, this is a natural result, and I think it is acceptable. Because the alternative way is not to have a UI for these modules and rebuild it from scratch for your application if you want to use that module.
So, we will work on such an hybrid UI system to allow developers to use UI of a module in case of that module has no native UI package for the technology they are working with.
While I understand the reasons this is attractive to ABP, the amount of additional complication that is added for end users is horrible. If you aren't going to support a technology, then fine. If you do support it, then support it cleanly. There is already a MASSIVE learning curve to begin using ABP, mixing UIs would create a product we would have never chosen to use.
This idea would cause us to stop using ABP completely.
Azure AD is customizable https://learn.microsoft.com/en-us/azure/active-directory-b2c/customize-ui-with-html?pivots=b2c-user-flow So Keycloak and others So to say that "look & feel" doesn't matter seems like an inaccurate statement to me
I hoped that Abp.Io would go towards innovative technologies and therefore also its modules would go in that direction. For example, I expected that in the next versions the OpenId part would be migrated to Blazor. So also the other modules and MVC would be "deprecated". Otherwise I would have stayed on AspNetZero. The choice to switch to Abp.io was given to be able to use Blazor natively and optimize our time without having to learn a different language. If you plan to continue using MVC you will add complexity for releases and deployments as well as you will continue to make us carry dependencies on deprecated libraries that can create security holes.
This is my opinion.
I think this might need some more attention. Maybe publish a blog post outlining these plans, and see what your users have to say about it first. I'm not sure how all this works, we're an Angular shop, so somehow you would proxy e.g. a Blazor UI into Angular? So customizations would need to be done in Blazor, not Angular anymore? This would not fly with us here I think.
Or is this really "just" for e.g. Community-built modules that don't have the expertise to implement all UI-Frameworks, but the ABP-first-party Modules are still provided as they are now, with fully featured UI-Framework specific Code?
While I understand the reasons this is attractive to ABP, the amount of additional complication that is added for end users is horrible. If you aren't going to support a technology, then fine. If you do support it, then support it cleanly. There is already a MASSIVE learning curve to begin using ABP, mixing UIs would create a product we would have never chosen to use.
This idea would cause us to stop using ABP completely.
@GMCfourX4 I didn't understand why you think of stopping using ABP because of that. Just don't use the hybrid module system, and that's all. We will already declare which module is native and which modules are hybrid (and what are the pros and cons of using them). You may not use hybrid modules, and you don't have additional complexity or a learning curve. But someone may need it. What is the problem here? There are hundreds of .NET features you don't use or even don't know (which can be very complex). Do they bring additional complexity to you?
Azure AD is customizable https://learn.microsoft.com/en-us/azure/active-directory-b2c/customize-ui-with-html?pivots=b2c-user-flow. So Keycloak and others. So to say that "look & feel" doesn't matter seems like an inaccurate statement to me
@RobertoFiocchiMCSI There is probably a misunderstanding here. I didn't say that hybrid usage is not customizable. You can customiza all. And it is much easier to customize a hybrid module's UI compared to customize Keyclock to make it looks similar to your UI. Because in our case, both of the modules will use the same ABP theming system.
Let me give an example:
We have a Forms module which is currently only implemented in MVC UI. We probably won't implement it for Angular and Blazor, as it has a very complicated UI and fewer people are using it. However, if we provide a way to use it in Angular and Blazor apps, some people may use it. It is better than nothing for them.
Here, a POC screenshot for this feature (it is POC, will be better in production):
In this screen, the application is Blazor WASM, an SPA that works properly for all pages and functionality. Only this Forms page is coming from the MVC UI (and rendered in an iframe here). It almost looks native and works pretty fast. The Blazor application (your codebase) does nothing, all done by the framework and an adapter module package (which knows how to render the MVC forms UI in a Blazor APP and has a very minimal codebase).
If you plan to continue using MVC you will add complexity for releases and deployments as well as you will continue to make us carry dependencies on deprecated libraries that can create security holes.
ABP's Blazor UI has almost all modules natively implemented already. Only the following modules are missing:
- Docs module (this was already built mainly for our own documentation and we wanted to give it to community as free)
- Forms module
When it comes to ABP Framework features, all are supported natively for Blazor. So, is it fair to say that ABP doesn't provide a native Blazor experience?
For example, I expected that in the next versions the OpenId part would be migrated to Blazor.
I didn't understand what do you mean here. OpenId login/register pages are only for MVC because it is a recommended approach for SPAs to use the authorization code flow and delagate the login process to a server-rendered application. The admin side of the OpenId module already has a native Blazor UI. What do you expect more here?
@MichelZ
I think this might need some more attention. Maybe publish a blog post outlining these plans, and see what your users have to say about it first.
This is why I created this issue here :) We haven't started the work yet (we are starting this week). We can discuss.
I'm not sure how all this works, we're an Angular shop, so somehow you would proxy e.g. a Blazor UI into Angular? So customizations would need to be done in Blazor, not Angular anymore? This would not fly with us here I think.
This is the only drawback, but it may not be so big problem as you think. Only the hybid-used module's customization requires to make customization on the Blazor side. All other application parts are native Angular. The current way to use that hybrid-used module, say the Forms module, to re-implement all the UI with Angular yourself (because it has no Angular UI). You can still do it if you want (because UI is another package in ABP, just don't use it). You don't loose anything. But for those don't need so much customization or can handle it, can use the Forms module's UI as a hybrid solution.
Or is this really "just" for e.g. Community-built modules that don't have the expertise to implement all UI-Frameworks, but the ABP-first-party Modules are still provided as they are now, with fully featured UI-Framework specific Code?
The core ABP Platform modules already has native Angular UI implementation and we will continue on that. But for some of the new modules, we may release the module with a single UI. For other UI options, you use it as hybrid if you want. If there is a demand on that module, we can implement the Angular and Blazor UI later. In this way, we ship the module faster. I am not saying that for essential core modules that should be fully integrated with the application on the UI level, but more business modules that may not be needed by all applications.
@hikalkan
I prefer not to mix different technologies/languages for usability and maintainability reasons.
The use of IFRAME is not recommended and some of our customers block them.
Also, the use of some modules is not accepted by our customers when there are security or licensing issues.
In the Docs module, you mentioned, the new "PDF Export" feature has been included via the itext library, which however requires a commercial license if used in a commercial application like mine.
I think that using Blazor instead of MVC would have removed the dependencies on jQuery and other poorly maintained libraries making my application more reactive and open to new scenarios.
For example, also authentication is now available natively in Blazor with local authentication Blazor Identity UI (Individual Accounts)
I know it is different than using a SPA application with OpendId Server, but going towards Blazor WebApp I expect something like Secure an ASP.NET Core Blazor Web App with OpenID Connect (OIDC)
I don't know if there is a technology that allows you to write components that work everywhere, but that's the idea behind WASM.
@RobertoFiocchiMCSI
I prefer not to mix different technologies/languages for usability and maintainability reasons.
I respect your decision. You already can not use the Forms module's UI in Angular, so continue not to use it, that's all. Nothing becomes worse for you.
The use of IFRAME is not recommended and some of our customers block them.
I know why you don't like and prefer iframe. We are also investigating WebComponent approach. However, it seems can not provide what we are trying to achieve. We are still working on it.
In the Docs module, you mentioned, the new "PDF Export" feature has been included via the itext library, which however requires a commercial license if used in a commercial application like mine.
We can not implement a PDF creator library just to add a PDF export feature for a module. We use the most reasonable pre-built library for such generic features. If you don't want to buy their license, just don't use that feature in the Docs module (which is already optional). Also, many times, we have less control over the licensing of 3rd-party libraries (like AutoMapper license change). We do our best not to depend on a commercial library from the ABP Framework to keep the ABP Framework fully free and open source. If there is no other way, we try to make it optional. But we can not promise all ABP features, especially integrations to 3-rd party libraries, will be completely free. Just don't use a feature if you don't want to pay for it.
I think that using Blazor instead of MVC would have removed the dependencies on jQuery and other poorly maintained libraries making my application more reactive and open to new scenarios.
Fortunately, we have been supporting Blazor from its first days. No problem with that. But I don't think MVC UI is bad. Many people don't like Blazor too for several reasons. It is another discussion. We like and support both of them :)
For example, also authentication is now available natively in Blazor with local authentication Blazor Identity UI (Individual Accounts)
We are investigating that. However, changing these things is not so easy and fast. ABP's current solution is stable and works great. Even Microsoft couldn't provide a solution (and used IdentityServer, even after they made it commercial) for many years for Blazor authentication; you remember the discussions on that.
I think the term “Hybrid UI” might be causing some confusion here. What we’re actually proposing is UI embedding, not a true hybridization or mixing of frontend technologies.
Let me explain it more precisely:
This feature is about rendering a UI page or component from one framework (say, MVC) inside an application built with another framework (like Blazor or Angular), without merging the technologies at the component level. There’s no cross-compilation or technology fusion involved—each UI remains fully encapsulated in its own tech stack and runs independently.
So when we say a Blazor app can “use” a module like Forms that's only implemented in MVC, what we mean is: that MVC UI is embedded—like loading a full, styled page or component—via iframe or similar method. The host app doesn’t need to know MVC to render it. It’s a drop-in page that seamlessly blends into the existing application, especially for modules that are admin-focused and not frequently customized (forms, docs-admin, cmskit admin etc.)
This does not bring additional complexity to the consuming developer. If anything, it lowers the barrier—because you no longer need to reimplement the same module UI three times just to support different frontend stacks. Your Angular or Blazor app remains clean and native. You either use the embedded UI as-is or, if you want full control, you still have the option to implement your own.
Lastly, native UIs for core modules are not going anywhere. The embedding approach is optional and targeted mostly for community-contributed or rarely used modules where building three separate UI versions would be overkill.
So, it's more accurate to call this UI Embedding, not a true Hybrid UI system. That distinction is important to prevent misunderstandings. Should be call it as "Embedding" @hikalkan ?
@enisn Sorry, but I didn't understand well.
Even if it were "embedded" to run that module it must reside on an application server where .Net is installed and therefore I cannot use it in a standalone static application like Angular and Blazor WASM. To run that module I would have to create an additional application server, which is another resource to configure, manage and pay for.
If I wanted to customize the code today I can "overwrite" starting from the code (Blazor or Angular) of the module, tomorrow I will have to rewrite everything, paying attention also to each release I will have to somehow replicate the fixes and new features.
It seems to me that everything is much more complicated to manage on our side. It is easier to say that the modules are ready to use as-is and that any changes are the responsibility of those who use them. But I don't think this is correct for PRO modules (already existing or new ones to come)
As a long time abp.io user who traditionally only uses MVC, I have always felt the amount of support the abp.io team does for different application level platforms must be hard to maintain. At the same time, I can unequivocally say one of the most difficult things to do in abp.io is to NOT use one of the out of box abp.io themes. I've successfully done this a few times (using a different third party admin theme), but the "lift" is heavy.
The only reason I bring this up is because as abp.io has added news tech (MAUI, Blazor, etc) it gets more and more difficult to decide on which app level platform we should be building on. As much as abp.io has done a great job at componentizing their front end modules, it almost seems like there is a layer of "UX Components" that we are missing. Even within just the "MVC" apps, the application layer and themes are "big", while the native abp UX components seem small (helper tags, extended datatables, etc). and even if I choose a different theme (LeptonX, Lepton, whatever) other major components require different implementations (I'm talking to you NavComponents).
and I get it; this isn't a rant. But I think the same problems I have swapping out any native abp theme and trying to use someone else's is the same core issue that we are discussing here. and I'm just wondering, perhaps incorrectly, if a more componentized approached in the UX may be the way to go here. Rather than trying to build these pre-scaffolded apps, what if we had a series of UX components, some shared, some only available on different platforms.
like I said, I know this is already provided at a certain level, but I feel like there's something we could do by extracting the UX components even more into a series of "themeless UX libraries".
maybe even chose an existing component library that already goes all-in on all the various platforms and build deep support for them with some layer of integration? (some extensive Flutter component library or some awesome third party MAUI component library for example) Why reinvent the wheel here?
Just food for thought.. I could be totally off track.
@jasenf
Just food for thought.. I could be totally off track.
Yes, actually, but no problem :)
ABP is a full-stack framework, while its main focus is to solve problems on the server side, especially when you want to build modular or distributed systems, create multi-tenant solutions or implement DDD and other architectural patterns to build maintainable systems.
What we definitely don't want to do is create a UI system like Telerik or Devexpress. That's another product. The scope of ABP is already big enough, and we don't want to include a product that would normally be sold separately and would require a large investment, just as a feature in ABP.
@RobertoFiocchiMCSI
To run that module I would have to create an additional application server, which is another resource to configure, manage and pay for.
I just wanted to clarify that there are ways to not add an additional application. You already have an HTTP API server (which is an ASP.NET Core application and responds to client requests). You can add a module's UI NuGet packages to that application, and it can start to serve the UI pages for that module too.
By the way, actually, you can do that now: You can use the Forms module's UI in your system even if you are building an Angular app. But it will be hosted in a separate application with a separate URL, and you will need to log in again when you switch to that URL. The Forms module is actually similar to Google Forms, and if you use Google Forms, your users will go to another application. While it is another UI application for the Forms module, it still will use the same database and server-side HTTP APIs as your application. That gives you a chance to reuse its entities, integrate into your application/business logic or customize the backend logic. That is currently possible, and I think it is reasonable to do it now if you accept that style of usage.
What we are trying to achieve here is to eliminate the need for another application with a separate URL for the Forms module UI, while making it usable within your Angular application. This includes navigation from the main menu and ensuring it feels like a part of your application.
To run that module I would have to create an additional application server, which is another resource to configure, manage and pay for.
Volevo solo chiarire che ci sono modi per non aggiungere un'ulteriore applicazione. Si dispone già di un server API HTTP (che è un'applicazione ASP.NET Core e risponde alle richieste del client). È possibile aggiungere i pacchetti NuGet dell'interfaccia utente di un modulo a tale applicazione e può iniziare a gestire anche le pagine dell'interfaccia utente per tale modulo.
@hikalkan
I suspected an answer like this :)
My API server must only provide APIs. If I add that it must also provide UI, I will need to configure CORS and open my backend server to vulnerabilities introduced by UI modules. If I need to release a fix (only GUI) for the Form module and this is embedded in the API service, I will have to block the APIs. If my API service is under load balancer or is serverless with autoscale, I should be careful in the configuration, if the module allows it.
But I already know that now you will answer that I can keep everything separate and it will be my choice.
Of course an embedded module is more difficult to extend.
For example, if the Users Notification module finally arrives and this will be only MVC for me it will be a joke.
@RobertoFiocchiMCSI The Users Notification module will not be an embedded module. Of course, it will be natively implemented for all UIs.
For your other thoughts, it is your architecture, I can not say anything. If it doesn't fit your case, just don't use that module (you already can not use it now, so nothing to lose).
While I understand the reasons this is attractive to ABP, the amount of additional complication that is added for end users is horrible. If you aren't going to support a technology, then fine. If you do support it, then support it cleanly. There is already a MASSIVE learning curve to begin using ABP, mixing UIs would create a product we would have never chosen to use. This idea would cause us to stop using ABP completely.
@GMCfourX4 I didn't understand why you think of stopping using ABP because of that. Just don't use the hybrid module system, and that's all. We will already declare which module is native and which modules are hybrid (and what are the pros and cons of using them). You may not use hybrid modules, and you don't have additional complexity or a learning curve. But someone may need it. What is the problem here? There are hundreds of .NET features you don't use or even don't know (which can be very complex). Do they bring additional complexity to you?
@hikalkan The comment about optional .NET modules we don't use is not on point here - you want to change the CORE of ABP. You aren't changing a feature we "don't use or don't know", you're changing the core part of the product that drove us to buy it in the first place!
We chose ABP because we WANT to use a lot of what you provide. That's exactly the sales pitch that won us over - ABP does the "core" things, and provides a UI we can use or lightly modify. We then focus on the rest. If you don't continue to create your UI in Blazor, now the entire benefit of "ABP will build the 'boilerplate' modules and UI" has gone away, since we will have to hire new talent or retrain existing talent in a different technology to continue to get benefit.
This seems like a dramatic change that is being thrown at users without a good discussion, and without enough consideration.
We have been very happy with a huge portion of the ABP framework, and what we are attempting to do (which I believe is in agreement with the 'intent' of ABP) is to allow ABP to do the vast majority of "common" or "boilerplate" functionality, and try to focus our own developers on adding our business logic.
The problem comes with how much of a learning curve there is, and how much we have to do to stay current with ABP. Each release of ABP causes us weeks of work to ensure that we have properly incorporated the changes ABP published (as a commercial user, this includes the source code as well). When it comes to the "common" UI, we look at the changes made by ABP, and consider whether the pages we customized for end-users need changes or not. Right now, everything is in Blazor. You're proposing a "hybrid" scenario, which sounds to me like we would need an MVC or Angular expert who is ALSO a Blazor export, in order to keep our customized pages in sync with ABP. In short, we're a tiny shop, and that would exceed our capabilities.
Just onboarding a new developer takes months in order to help them do things "the ABP way". We WANT to have everyone follow the "ABP way" because it ensure consistency and often provides benefits in areas that not everyone had thought ahead to yet. The idea of having to know different UI technologies in order to use the ABP UI just creates a LARGE jump in expertise required by us, to the point that it becomes harder and harder to justify.
Please reconsider this avenue. As others have said above, perhaps discuss focusing on only Blazor, or only Blazor and Angular (I don't know the breakdown of your users' implementations).
Just food for thought.. I could be totally off track.
Yes, actually, but no problem :)
ABP is a full-stack framework, while its main focus is to solve problems on the server side, especially when you want to build modular or distributed systems, create multi-tenant solutions or implement DDD and other architectural patterns to build maintainable systems.
What we definitely don't want to do is create a UI system like Telerik or Devexpress. That's another product. The scope of ABP is already big enough, and we don't want to include a product that would normally be sold separately and would require a large investment, just as a feature in ABP.
@hikalkan This suggestion might actually be a better way to "split the baby". ABP already has many "magic" parts that abstract away much of the boilerplate code. Could this be extended to a small number of common UI elements? If a grid is used with built-in sort and filter capability, then most simple scenarios could probably be handled with a grid page and an edit page. Maybe there is an option to create a "template" grid, and a"template" page with one or more entry fields, and have a class that will "explain" how to build the UI and DTOs? Then you wouldn't need to build an Angular page, an MCV page, and a Blazor page - you could just have a few templates (base page, grid, form) which would be combined into each supported UI?
@enisn If I wanted to customize the code today I can "overwrite" starting from the code (Blazor or Angular) of the module, tomorrow I will have to rewrite everything, paying attention also to each release I will have to somehow replicate the fixes and new features.
It seems to me that everything is much more complicated to manage on our side. It is easier to say that the modules are ready to use as-is and that any changes are the responsibility of those who use them. But I don't think this is correct for PRO modules (already existing or new ones to come)
I would like to echo this sentiment. Part of the value we get from ABP is that we have the "boilerplate" code done for us - if we need to make a small change we can. This new model would require us to rewrite everything ourselves any time we need to make a small change.
Since we're using Blazor WASM, we also expect to be able to build a MAUI/Blazor hybrid app with offline capability. In this hybrid scenario, how would a hybrid ABP screen load if the app was offline?
@hikalkan
This is why I created this issue here :) We haven't started the work yet (we are starting this week). We can discuss.
This is an example of a change that causes users to be frustrated and upset. This is a major change, and not enough time was given for discussion and consideration of the impacts on your users.
This change can cause significant problems for some users, but your comments make it sound as though our input is ignored, the plan was already decided, and we are only being "told" and not "asked".
There are many thoughtful and insightful users, and a number have posted here. Please consider this input before moving forward.
@hikalkan As a commercial ABP user for 3 years now I can tell you my experience with modifying various aspects of the UI and functionality to fit our projects requirements is not trivial at all and by making the UI aspect even more complex (in my opinion) this will only increase.
The ABP modules out of the box are just fine if your project does not deviate from ABP's look and feel, page layout across the site or on individual pages, etc....but most projects don't start with "it needs to be like what abp gives us". I have spend days if not weeks trying to figure out how to remove or add different functions from a given page only to learn by doing so typically 'breaks' how it sets various things for the ABP backend causing issues in other parts of the application that become a nightmare to trace down.
If I create a ticket each time I encounter these issues, I would quickly burn through our companies allotment of yearly tickets. The typical support response is 'please provide a test project demonstrating the issue' which is most of the time not feasible because user's don't have time to recreate everything that could be a factor into the current issue we're trying to solve....all without a guarantee that I can successfully recreate the issue at all. Very frustrating!!! Often I've asked specific questions all bulleted out for support to address and more times than not those questions are not answered in totality and often the ones that are answered are so off point that the conversation becomes confusing for the support folks.
Making the UI framework more complex (again in my opinion) will increase the issues I will have (for sure) and my frustration with support on not being able to pinpoint the cause when I encounter all the issues I have in the past.
In all your tech talks you promote the ABP Community as being a great benefit of your products, and I agree as I have had other ABP users reach out to me for help with the framework, but yet you are getting feedback here where people are expressing concerns but yet in your own words despite these concerns ".....We haven't started the work yet (we are starting this week)....." Doesn't really make a user (let alone a commercial user), feel like a strategic partner of ABP's
Just food for thought.. I could be totally off track.
Yes, actually, but no problem :) ABP is a full-stack framework, while its main focus is to solve problems on the server side, especially when you want to build modular or distributed systems, create multi-tenant solutions or implement DDD and other architectural patterns to build maintainable systems. What we definitely don't want to do is create a UI system like Telerik or Devexpress. That's another product. The scope of ABP is already big enough, and we don't want to include a product that would normally be sold separately and would require a large investment, just as a feature in ABP.
@hikalkan This suggestion might actually be a better way to "split the baby". ABP already has many "magic" parts that abstract away much of the boilerplate code. Could this be extended to a small number of common UI elements? If a grid is used with built-in sort and filter capability, then most simple scenarios could probably be handled with a grid page and an edit page. Maybe there is an option to create a "template" grid, and a"template" page with one or more entry fields, and have a class that will "explain" how to build the UI and DTOs? Then you wouldn't need to build an Angular page, an MCV page, and a Blazor page - you could just have a few templates (base page, grid, form) which would be combined into each supported UI?
Right, I'm not suggesting abp try to build or compete with Telerik, I'm just identifying the complexities I encounter when trying to build a new app. Any change to the Out of Box abp.io themes/components is a heavy heavy lift, so I was just thinking outloud about some layer more significant than the helper tags and client side utils, but not as rich as a component library.
Something that may kill two birds with one stone: lets us make front end apps in a more timely and productive fashion, and, perhaps deal with some abstractions that the abp.io team is going through trying to deal with different platforms. No one needs a new Telerik, but abp could use an out of box "login", or "register with new tenant", or fully tied in navigation component, and probably 50 other similar higher-order components...
like, code you already have but componentized outside of the themes. extract these, then build to the different platforms. thinning out the actual client side (web, maui, angular) apps even more.
@GMCfourX4
I read all your comments. Thanks.
you want to change the CORE of ABP
As I see, that is the main thing we think differently. We don't see that as a core change. We do less thing in the core framework level. We do that to provide a way to allow developers to reuse modules that are currently not available for their UI technology. That's all.
@hikalkan
As I see, that is the main thing we think differently. We don't see that as a core change. We do almost nothing in the core framework level. We do that to provide a way to allow developers to reuse modules that are currently not available for their UI technology. That's all.
I understand your thinking, but I think the best thing in terms of community is to engage the community itself.
For PRO modules you can choose to leave them paid and then I expect Volosoft to create the UI for every language the framework supports, or you can make them FREE (open source) and leverage the community to improve the module.
So, for modules that don't support UI for some technologies, you can hire an active community user to do the work. You would act as certifiers of the work done.
@spospisil
In all your tech talks you promote the ABP Community as being a great benefit of your products, and I agree as I have had other ABP users reach out to me for help with the framework, but yet you are getting feedback here where people are expressing concerns but yet in your own words despite these concerns ".....We haven't started the work yet (we are starting this week)....." Doesn't really make a user (let alone a commercial user), feel like a strategic partner of ABP's
We are listening to community, of course. And discussing all these in the team internally to decide what to do.
On the other hand, we are not so sure that this approach (what I offered) is practical and usable. So, we are currently working on a draft implementation to see how it will work. It is a kind of R&D. But this work is not something that will take so much time. Our implementation idea is simple and probably we can complete a working solution in a few weeks (I made this POC working in a few hours)
Another problem that we are trying to solve with this work is that:
We are currently working on a Workflow module for ABP Platform, which will be based on Elsa Workflow. The problem here is that Elsa only provides a Blazor UI for its Workflow designer UI. We don't have a chance to create an MVC and an Angular UI for it (it would be a huge effort). A hybrid usage would make it possible and easy to use the Elsa Workflow designer as embedded into MVC and Angular applications.
Another problem that we are trying to solve with this work is that:
We are currently working on a Workflow module for ABP Platform, which will be based on Elsa Workflow. The problem here is that Elsa only provides a Blazor UI for its Workflow designer UI. We don't have a chance to create an MVC and an Angular UI for it (it would be a huge effort). A hybrid usage would make it possible and easy to use the Elsa Workflow designer as embedded into MVC and Angular applications.
Will it be a Free or Pro module?
For MVC what are the issues? Elsa has its own dashboard that runs fully on .Net Core so the same MVC server can provide the Blazor service. Like this Integrate ASP.NET Core Razor components with MVC
For Angular I saw that there are already development plans V3 designer/angular wrapper
I hope I helped you
Will it be a Free or Pro module?
It will be a pro module.
I will check the links you've provided.
I am not sure if this is feasible, But sharing my thoughts. How about building module UIs as Web Components, and reuse them across MVC, Blazor, and Angular applications. These components would encapsulate functionality and visual behavior into framework-independent custom elements (e.g.
It can be embedded in MVC / Razor Pages like regular HTML tags and Blazor (Server/WebAssembly) via JS interop and native tag usage also, in Angular Custom_Element_Schema
By doing so it can be more productive to write once and use it everywhere.
Challenges with details mitigation. For example: dealing with events, context sharing etc..
Will be framework price be decreased or open source more modules? Eventually increase the number of requests that owners can submit?
Will be framework price be decreased or open source more modules
We are not considering changing (at least decreasing) license prices. For more open-source modules, we are open to community contributions. If a single module UI can be usable in different technologies, this may encourage community contributions. For example, these guys (https://easyabp.io/) build many free ABP modules, but they only provide MVC UI.