This is what I am working on, to hopefully have up this week...
@mikesmeltzer To my knowledge, with Blazor, you must always use IJSRuntime (JavaScript Interop) when using JavaScript. However, it is not hard at all. See: http://blazorhelpwebsite.com/Blog/tabid/61/EntryId/4317/Blazor-JavaScript-Interop.aspx
Thanks for the info. I watched a good Blazor intro video from Build, this makes more sense now.
@mikesmeltzer From what I have seen so far I would use it to build both. My definition of app could be a blogging platform, it could be an enterprise portal that runs an entire intranet with mini-apps scattered throughout. Oqtane doesn't appear to have any content management tools, doesn't mean it can't be done.
3 replies
I am most interested in what Oqtane can do with authentication and user management. If it has the ability to use something like the DNN Auth Providers, I can utilize it for our IMS system I build for police depts.
Can a module developer use a third party Blazor UI component and package it in their module without affecting any other installed modules?
@thenrich2009 the forum on the oqtane.org site was being bombarded with spam every day so it was removed 3-4 months ago
@thenrich2009 the other modules on Github are in the process of being upgraded to the 1.0 framework release - there are only so many hours in day. But yes, Oqtane modules and themes can be packaged as Nuget packages ( *.nupkg - which includes the release bits and a manifest ) that can be deployed at runtime into an Oqtane instance just like with DNN.
@ahoefling the question which @mikesmeltzer asked above is exactly what I was referring to when I was saying that if you call something a CMS, some people will expect a system with content-centric features - which is not the current goal for Oqtane. Honestly, if I was asked to build a CMS I would use a completely different architecture - it would need to be content-centric from the repository layer up. Oqtane is app-centric - not content-centric.
based on the effort to get cookie-based auth to work in both Blazor Server and Blazor WebAssembly I would not say it is a simple undertaking
Especially Blazor Server has its set of challenges because of the reliance on SignalR
@ADefWebserver_twitter is currently creating one and his goal is to have it published this weekend
So far no luck on installing Oqtane on Azure :( See: https://github.com/oqtane/oqtane.framework/issues/168#issuecomment-632963982
@thenrich2009 you might find this presentation useful as it explains the differences between Blazor Server and Blazor WebAssembly https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwjkuu6-mcvpAhVHn-AKHVrBAx8QtwIwAnoECAoQAQ&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DoRbdjmBhYpE&usg=AOvVaw1GDtVdp3ov7J2pdCN8eF7J
@sbwalker Before I spend 1.5 hours watching it and me knowing many of the differences, I am asking specifically what are you losing by not supporting server size Blazor and just go full speed ahead with Blazor Wasm? I know a lot of people were waiting for wasm and they weren't terribly excited about SignalR and all the open connections and the server responding to every click the user makes in the browser. Are users going to be angry if you don't support server side Blazor?
In my personal opinion a lot of the people who had a negative reaction to Blazor Server never actually tried to use it, they made their judgements based on theoretical aspects and speculation. If you speak to developers who actually used Blazor Server you would discover that the majority are very satisfied with it. The one significant development benefit of Blazor Server is the simplified architecture - which results in more rapid application development. Specifically I am talking about the fact that if you are only going to target Blazor Server you do not need to develop your applications in a client/server model - you can create razor components that call EF Core directly for data access - you can avoid all of the overhead of API controllers, service classes, etc...
That being said, one of the most significant advantages of a SPA architecture is that the UI processing is offloaded to the client - so there are benefits to the extra overhead required to build a client/server application. It really depends on your specific application requirements.
In my personal opinion a lot of the people who had a negative reaction to Blazor Server never actually tried to use it, they made their judgements based on theoretical aspects and speculation. If you speak to developers who actually used Blazor Server you would discover that the majority are very satisfied with it. The one significant development benefit of Blazor Server is the simplified architecture - which results in more rapid application development. Specifically I am talking about the fact that if you are only going to target Blazor Server you do not need to develop your applications in a client/server model - you can create razor components that call EF Core directly for data access - you can avoid all of the overhead of API controllers, service classes, etc...
... I could not have said that any better :)
I am in the process of converting a Server Side Blazor example application into WebAssembly for an article. This process is very challenging. Basically there is a lot of extra code. Another interesting thing, the application is slower not faster. In the typical Line Of Business application, practically every click is a request for data from the server or to send data to the server. In these cases the advantage of WebAssembly to 'process everything on the client' is not materialized.
I've spent the past few days rebuilding what I started in the pre-1.0 release of Oqtane with the latest version, discovering a lot of changes in the code but finally getting my two custom modules working again (the first module is a simple list builder while the second module allows me to dynamically assign individual elements to those lists). In the second module, I therefore use a list dropdown to view/add/build ONLY those elements associated with the list selected. I even managed to figure-out how to pass the selected list ID through the query string and such.
Right now, the list dropdown is embedded directly into my second module, but I'm thinking it really should be a separate component, so I can reuse it elsewhere (and learn how that's done). So, is there a best practice for assigning custom components within the Oqtane framework? For example, should they be placed in Oqtane.Client.Modules.Controls? Should they perhaps go into the Oqtane.Shared project? Just wondering where I should place these custom components.
I'm also wondering if there's a way to customize the default Oqtane components so that when the framework itself is updated my customizations aren't overwritten. For example, I customized the AuditInfo control so that when a record ID is passed to it, that ID is seen along with all the other audit data. However, I'm guessing that the next time I go to update the overall framework, that customization will be overwritten. Any advice on that as well?
Yes they haven't tried server side Blazor but it's not the only option available for Blazor and that's not the point I am bringing up. If you ask any developer which Blazor option would they choose, the one which keeps connections open all the time while the user is on the site and every web interaction is handled by the server or the option where the client handles everything.. like every existing webpage now? I think they will choose client side. Anyway, if you're happy supporting both and Oqtane is not going to be majorly complicated because you're supporting both hosting models, go for it. Personally I would go for client side even though it's a little more complicated to develop with. I think you posted having issues with SignalR? These are the extra distracting issues that server side Blazor might be bringing to the ride.
@ADefWebserver_twitter The difference in the two scenarios where the server doing processing is that Blazor needs open connections all the time and that can cause issues. I tried server side Blazor and for some reason sometimes the connection breaks and the app breaks. The second common type of server processing is stateless. The server is just doing gets and posts. It's only about data. It's not processing every click which doesn't need data processing.
"Are users going to be angry if you don't support server side Blazor?" - the answer to that depends on "which users" - it would really depend on the target audience for your specific application"
Users here are developers or users of an app made by Oqtane? Because Oqtane users do not care which Blazor was used. So I guess it's developers. Why not ask the developers which model they will be using and see if there. if any, will certainly use server side. They first need to know what they will lose if they chose server side, like the inability for the app to work a PWA one.
Users here are developers or users of an app made by Oqtane? Because Oqtane users do not care which Blazor was used. So I guess it's developers. Why not ask the developers which model they will be using and see if there. if any, will certainly use server side. They first need to know what they will lose if they chose server side, like the inability for the app to work a PWA one.
@thenrich2009 when you originally asked the question "Are users going to be angry if you don't support server side Blazor?" I thought you were speaking hypothetically about your own applications - but I now realize you were asking about Oqtane. The ability to support multiple Blazor hosting models is a foundational principle of Oqtane - it is documented in the Oqtane Philosophy under "Flexibility" - https://www.oqtane.org/Resources/Blog/PostId/538/oqtane-philosophy. Considering the fact that Blazor WebAssembly was not even released until last week, support for Blazor Server was critically important to the development of Oqtane and the majority of the early adopters are using Blazor Server. I will admit that I originally assumed more people would be interested in Blazor WebAssembly however I have since learned that there is a large group of developers that appreciates the simplicity of the Blazor Server model. The fact that Oqtane supports both hosting models seamlessly means that the community can accommodate both groups of developers. And I am excited for Oqtane to be able to support future hosting models such as Electron, etc...
To me it is a MAF or a Modular Development Framework (MDF) which covers a lot of CMS's in my mind just without the workflow. You can build a mod with workflow in mind... but I really believe this project is more focused on giving a framework that utilizes modern architecture and ease of development. I really feel like you can build anything faster than ever before. DNN I still cannot fire up a site to fix a simple bug, i fly by the luck of it all hoping when they release my fix it works... embarrassing in a way. It just takes so much time to lookup things. This is night and day to webforms development... awesome and I cant talk about how much fun I am having learning while reading about all the tweaks being done to get to this point. I feel lucky to have a project like this to contribute to. Thank you everyone for supporting this. I look forward to Oqtane in 1 year. The rubber just hit the road for Oqtane and Blazor... now watch it grow.
and new people can find their way more easily down the road from our talking points about a subject or matter
It will take a lot of oqtane (coffee) to get there but it can happen.
I would recommend anything Blazor community recommends should be in Oqtane at some checkpoint
I just put a few PR's up and Andrew I was trying to get the bug you had to work... could not make it happen maybe we are missing something