Oqtane Ecosystem

[hishamco]

I'd like to take the moment and share share some thoughts and peeks that ma help to drive or improve the project

1. Oqtane Team

I already told @sbwalker before v 1.0.0 release to start create a core team for this project to move the project forward and start working on a new features regularly, I'm requesting Shaun again to think about this point and choose and request the active members to be a part of this ecosystem, if they willing to move this project forward

The team could not be code only, docs may be included too

2. Oqtane Repositories

It would be nice if we created other repositories such as:

• Oqtane.Modules

• Oqtane.Themes

• Oqtane.Docs

• Oqtane.Translation

• Oqtane.Samples

that may help both the team and community, of course we can start for the important once and keep adding the others

3. Oqtane Market Place

@sbwalker is already opened a discussion here

4. Oqtane Future

I'd like from @sbwalker to start share his though about the upcoming minor and major releases milestone with the help of GitHub Projects and Milestones to organize the features for the future, of course the community will be a part of it and Will Be Open for Public

5. Oqtane CI/CD

I'm still requesting @hishamco for Continuous Integration and Continuous Delivery for the project, that will help to check the current build and save us time from regression bugs which we already suffered a lot in the past ;) I already opened an issue long time back in #227

6. Oqtane Testing

I'm still believer on testing, we need to add more unit tests, functional testing as well that well ensure that our framework is solid and testable, of course this will improve the quality and increase the code coverage

Integration tests may added too

7. Oqtane Gitter

I'm not sure if we can keep the gitter for this project or shall we replace it with GitHub discussion, the important thing that we keep the community and team engaged

At the end this my humble opinion, all the feedback is open and we can keep adding a list items if it's necessary

[markdav-is]

I think @sbwalker has a great project started and I know I'm committed to making it a success. Running open-source projects is messy and sometimes there is not enough bandwidth to hoist most of the code and run the community. My suggestion would be to meet weekly for an hour and run thru the Mozilla Open Leader series for 12 weeks. Give the project a point-in-time mission/vision and onboarding infrastructure. https://mozilla.github.io/open-leadership-training-series/

quick thoughts on your points:

1. Oqtane Team - contributors become core contributors by contributing and getting PRs accepted, no reason to name folks as that creates an inner-circle
2. Oqtane Repositories - anyone can create modules, samples, and themes as separate repos, so no need for mono-repos for those. There is an "Awesome Oqtane" repo that can be updated to link other repos in the ecosystem. Docs sounds great!
3. Oqtane Market Place - feels like a separate effort from the main product, but tightly integrated.
4. Oqtane Future - milestones are an artifact of the Mozilla training, if that's followed.
5. Oqtane CI/CD - you can set this up for a fork, the releases are packaged, so I'm not sure where this would get deployed.
6. Oqtane Testing - Tests are nice. Make it part of the main repo. bulking up issues for those could attract contributors.
7. Oqtane Gitter- I thought this was abandoned for discussions.

I can take on some administrative tasks and run the mozilla training, weekly meeting if you like.

[kevind2000]

The Mozilla training sounds interesting, what would be the goals & outcomes? would it be open to all?

[markdav-is]

the Mozilla open leadership training is primarily for project leads and advocates. it's helps you attract and onboard contributors, plan milestones and put effort into the project that helps guide it's future. Folks do this in parallel with the actual project work (coding) and provides another way to contribute. most successful project has a single lead, but having multiple folks attend meetings and take on tasks is helpful. Following the guidance is a way for folks to follow along as well as build artifacts that can help others understand the project.

[kevind2000]

Thanks for the explanation. I see the value of going through the process since it's necessary to plan milestones and prioritize features while forming the team and searching the way of working together.

I still wonder what Oqtane Framework "Product Positioning" would be? I suppose I'd better ask the questions under @sbwalker's discussion #732.

[sbwalker]

I appreciate @hishamco raising this topic as I have been thinking a lot about this myself lately as well.. For the past 2 months my fullt-time job has been extremely demanding so I have not been able to devote as much time to Oqtane. Fortunately, the Oqtane MVP release which was coincided with .NET Core 3.2 has proven itself to be very capable and stable and offers a solid foundation for the future. However there is still much to do to improve the framework... and there are many community members who are eager to participate.

And I certainly do not want to discount the suggestion above by @nohorse as I am a big fan of Mozilla but I personally feel that Oqtane is already well beyond the majority of the items offered in their training series. In particular, the product is already past a 1.0 release, it is already open source ( under an MIT license from the .NET Foundation ), the community infrastructure is already established, a community has formed, etc... That being said, I will admit that some aspects are missing at this time and need to be addressed. Most importantly, the product needs a roadmap and a way for the community to get organized and participate in the evolution of the product.

Before getting into the details of next steps, it seems that there is still some confusion about the product. I had hoped that by publishing the very detailed blog post about the Oqtane Philosophy as well as presentations and videos which contain high level messaging about the product purpose and positioning, it would have addressed these points:

https://www.oqtane.org/Resources/Blog/PostId/538/oqtane-philosophy

Please review the blog and I would be happy to clarify anything which is unclear. If you feel this messaging needs to be shared in a different form or location please let me know.

As far as a roadmap is concerned, we have already discussed one aspect of this in another discussion thread already... it is critical that we migrate Oqtane to .NET 5. In fact, for maximum impact, I think the Oqtane 2.0 version should be timed with the release of .NET 5... and the 1.0.4 release which was published earlier this week should be the final 1.x release. Please keep in mind that there are only 2 months until .NET 5 is released so we will need to make this transition ASAP. Ensuring Oqtane is 100% compatible will be the top priority and we will also need to evaluate some of the new features of .NET 5 to determine if they can be utilized in our dynamic framework ( I suspect that many cannot be used because they are based on static development scenarios ).

Beyond migrating to .NET 5 I think the Oqtane 2.0 release should also consider the following enhancements:

• migrate to code behind model ( *.razor to *.razor.cs )
• implement static localization support for UI fields
• replace tables in markup with responsive approach
• implement EditForm approach in all data entry scenarios

However in order to align with the Philosophy, we would only want to move forward with these items if we think we can implement them consistently across the entire platform in time for 2.0. So we would need to come up with a functional pattern and then implement that pattern across the platform.

In addition, we need to move forward with efforts related to CI/CD, testability, and documentation.

Thoughts?

[sbwalker]

Further info from Microsoft on the code behind approach "Either component authoring style is fine. They’re mostly interchangeable. We prefer the inline style, so that’s what we use in our templates and samples. We disagree that this encourages bad coding practices any more so then if you had a code behind file. A .razor file represents a single component class so any UI logic is part of that component’s concern and makes sense to live in the same file. You shouldn’t mix business logic in your UI layer, but that can happen just as easily if you’re using a code-behind file. The Vue community uses the inline style and do just fine. But we also understand that ASP.NET devs have been taught for a long time to use a code-behind file and many prefer it, which is totally fine."

So its really a matter of preference. I think the bigger question we have to ask is which style will appeal more to the developer community who we expect to attract to Oqtane? The JavaScript developer community such as Vue is not our target demographic. But if ASP.NET devs examine the Oqtane code and immediately have a negative reaction to the single file model based on their prior experience with WebForms, etc... it will hinder adoption of Oqtane.

[kevind2000]

I duplicate this from the discussion #739 under PR: [Yes, "either is fine", preferring the single file for UI component since it's chosen. For later, there might be possibility to use XAML not Razor syntax to define UI elements to support native mobile and desktop client, even C# code (fluent UI) directly for that matter, at that time refactoring to code-behind might be making sense - this is way down the road IMHO.]

After saying that, we might consider splitting the file when either UI elements or UI logic becoming too much - so far, the razor files in the framework are fine to me.

For ASP.NET Web Forms developers, they may like it since there would be less files in the solutions :-).

[sbwalker]

My understanding based on the Blazor Mobile Bindings and info shared about MAUI is that .NET is moving towards a unification of UI development models based on Razor components, and away from XAML.

[kevind2000]

Haven't looked at Blazor Mobile Bindings.

My understanding is that MAUI is based on Xamarin XAML, not even WinUI (another flavor of XAML under development for UWA-kinda) that UNO is based on (Xamarin also used). Personally, I would like to see XAML is unified first and wondering why they are not?

Razor is based on Web UI and CSS, hence big differences with XAML UI Model. Any links for the unification towards Razor components and away from XAML?

[sbwalker]

@kevind2000 Agreed that we need an mini-RFC for static localization. I will create a new discussion item for this.

[hishamco]

I'm with you Shaun, no need to move into .NET 5.0, the stability of the framework is very important to all of us, meanwhile I will start to file an issues for the listed items - if there're not logged before - , because I remembered some of them is already there before 1.0.0 ;)

In terms of testability I can dedicate sometime to do many things here, but I need your help into CI/CD or give me a permission and I will take care about it

Thanks

[sbwalker]

@louyo I don't think you offended anyone... and thank you for taking the time to do some testing. You did not indicate which version of Oqtane you were testing with so I am going to have to assume you were using the latest code in the repo? I am including some detailed feedback below...

1. Cannot reproduce. I have added an Html/Text module to multiple pages without specifying a title, and the system adds the module just fine and uses the module's type name as a default title. What module were you trying to add?
2. Do you have any details related to this "bad log entry"? It is impossible to reproduce or investigate further without some detailed error information
3. Correct - when you publish an app from VS it does not include the Content folder. Can you explain a bit more about your deployment - in particular your database. Were you sharing the same database between your local development environment and your remote published environment? I am asking because this is the only scenario where I can imagine the logo issue occurring.
4. During publish VS is only aware of statically linked resources - not dynamic resources such as external modules.
5. This is a feature enhancement
6. Giving access to a site administrator creates a security vulnerability as only host users should be able to view system internals included in log messages. This behavior is by design.
7. Enhancement request
8. This has been discussed previusly
9. .NET Core requires an app restart to unload/load assemblies into the app domain. This is by design. The next request to the server will automaticallyt restart the application.
10. Impossible to reproduce or investigate further without some detailed error information

[louyo]

Thanks for responding. I will press on. Only other comment I would make is that, when problems occur, I ask my users to check logs. Perhaps somewhere down the line, someone will step up and work on the UX.
Thanks again.

[sbwalker]

@louyo I was actually hoping you could provide some additional info related to my questions above so that we are able to try and resolve these issues. The fact that I cannot reproduce them seems to mean that you are using a different version or configuration or following different steps. The exact details of how to reproduce an issue is extremely important. I flagged some items as enhancements because they are not bugs... and as a result are lower priority but still relevant in terms of improving the overall system.

[louyo]

I am planning more/repeat testing but other stuff in the way. Like you, I have my priorities. I will say that all my testing is done by directly running the executable from the publish directories. W10, WServer, Linux.

[louyo]

OK, I started out with a new install of 1.0.4, was 1.0.3. This fixed some of my (self inflicted?) problems.
Here is what I still see:
Running in debug mode, deleting or installing an external Module stops execution and requires stopping the debug session and restarting it. In publication mode (running from oqtane.server.exe) causes a Crtl-C and forces me to restart. The latter is how I want to run.
I am uploading a zipped up Word file that has 2 unhandled exceptions. One is the error when I add 100 rows to the Event log page and then hit refresh. I doubt if you can recreate this one. Fortunately, it doesn't crash when running from the publish directory, but it doesn't add the rows. Both conditions shown in the docx.
The second is what happens when I open a new download of Oqtane and try to run the install with my database info. Since it recovers with a new debug session, it is probably not worth pursuing, but at least you know about it in the off chance someone besides me gets it. I suspect it is due to me changing from the default DB.
I have given my opinion and you have taken the time to give me yours, I appreciate that. I won't try to change yours if you don't try to change mine. :)
logcrash.zip

[mikecasas]

I like the fact of 1.0.4 being the last 1.0 release. 2.0 should begin on a dev branch, and that should be the pattern going forward, with new versions starting on a dev branch and then pulled into master.

The movement to code behind should be done in small bite sized PRs. People can volunteer for certain pieces, or be assigned using the tools in Github. Same for forms. This will help the community see progress.

Docs are number 1 priority.

CI/CD is needed. Github actions are great to kickoff builds, and create docker containers. Not on every commit, but a nightly build would be great.

The current project is great, but there is more to a good open source project than just the code - crazy as that sounds. We understand the demands and time constraints, we all have them, but we are here to help to push octane to even greater success.

[sbwalker]

@mikecasas agree on the branching strategy. Also agree that the work needs to be broken into granular PRs so that they can be reviewed effectively ( ie. we should avoid massive PRs which span the entire solution ). It will be beneficial if docs can evolve fairly independently from the code base. Above all - you are absolutely correct that open source projects are more than just the code itself.

[mikecasas]

@sbwalker do you also want refactoring done, to remove repititive code? I know you wrote it with simplicity in mind for developers to get started quickly.

I'm referring to things like the permissions in the site templates. Most of the admin pages get the same permissions. Would a helper method be better? Not a huge deal, but just citing it as an example.

[markdav-is]

GitHub flow with PRs FTW!