As we're making our initial move into DNN and setting up projects, I need clarification on the Web Application Project model for creating DNN modules.
Should/can all modules live inside one web application project? Or, should each module be its own WAP?
What would best practices dictate for the project structure in the solution containing DNN modules?
You can do it either way. I've heard people do it both ways.
Do your modules depend on each other at all? If so, you might want to keep them all in the same project so if one gets built, they all do.
If not, I like to keep each module in a separate project just from a separation standpoint. Each module/project will be smaller and easier to manage. Just build the project and it will give you the install file.
It's just a personal preference. I know a lot of people create one solution, then keep a separate project for each module.
Related
I'm planning to create a bunch of (2 to 3) ReactJS frontends that all primarily interact with the same existing Ruby on Rails API. Each frontend will appear on a different domain, but will use the same graphic design system and UI. Because of this I imagine that they will be sharing a lot of code.
How would you recommend organizing the code for such a project? And also how would you deploy it?
Code sharing
In my research I found the solution of creating a node package that just contains the shared components/code. My concern there is that then the developer (me) would have to be constantly bouncing from the module's repo to the repo for each site.
I also noticed bit but wondering if I want to be so dependent on a proprietary service.
These frontend sites don't really need to be completely isolated from each other in different repositories—even though they are on different domains, you could almost think of them as different sections of the same site, in the sense that they are closely related.
Deployment
If, for example, all this code is kept in the same npm project, then it's conceivable that when deploying, several build scripts could build each frontend and then push each build to a CDN. Would that be a good strategy?
I am creating a SaaS web app for online scheduling, and want to create multiple niche versions of this SaaS for different kind of businesses.
I want to know what's the best project structure for this.
I'm considering using forks or branches but I can't really decide what's the best for this scenario.
The sub-projects need to stay updated with the "core" SaaS project.
That means that when I fix a bug or add a new module (such as shopping features or theming) to the main project it is automatically available to all the other running sub-projects.
The features are going to be modular so new ones can be added or old ones removed.
Anyone can give me a light here?
Thanks!
Maybe you can use Lerna or yarn workspaces to share different modules across your applications.
Lerna: https://github.com/lerna/lerna
Yarn: https://yarnpkg.com/lang/en/docs/workspaces/
example: https://github.com/mui-org/material-ui/tree/next/packages
I want to use ReactJS for the front end of our new system.
The back end system (in C#) has different modules which can be toggled on/off. Each module has its own set of DLLs, meaning the product can be "shipped" without unnecessary module DLLs. "You need chat functionality? Here's the DLL, drop it in your bin folder, good to go!"
Each DLL is pretty much standalone with no dependency on an other, apart from it's main parent abstraction.
I would like to know, is it possible to create something similar in a React front end? I don't want to have hundreds of react components listed with a bunch of 'if' statements to show/hide them.
I would like each module to be responsible for its own rendering & actions. Adding a brand new feature would be as easy as 'building the extra module' (not updating the 'core' system files to tell it about the extra module).
Gah, I hope that makes sense! Could anyone point me in the right direction? Is this a fools errand? Is it achievable?
Thank you in advance.
This is more question of how to split your frontend code than react specific question. Good news is, it's certainly possible. Take a look at webapack - bundling tool often use with react. I am not sure how exactly modules and DLLs work in C#, but I imagine you have some way how to include different js bundles into them. If so, webpack will help you create these bundles.
I've been looking for tutorials on making modules for DNN, and all of them seem to suggest starting from a huge template and then adding what you need to it, but I'm sure there is a way to build a very small, lightweight module with just the barebones. Just use an ASCX view, and show it on the screen. What is the simplest hand-written "Hello World" DNN module? If you really do need a whole lot of extra stuff in a module for it to work, what is the cleanest way to get a module template?
Background: I've come from front-end development, and I'm looking for a way to package my front-end scripts and styles together, then just use a single file as an AJAX endpoint to query to retrieve the data.
Depending on your DNN version, there is an easy way to create a simple module within DNN itself.
When you go to "Host > Extensions", there is a button with something like "Create new module". Fill out the fields and it will create a module for you that you can use like any other.
When the module is added to a page you can edit the source code (C# / VB) in the module itself.
This is the fastest way to create a basic module. But I would still recommend the template from Chris Hammond. It is slightly more complex but will be easier to maintain and can be packaged as a standalone installer for other DNN installations.
I'm starting to build a rather big application in ExtJS Architect and I was wondering if it is advisable to split the application into multiple projects (to be precise projects as Architect defines a project)?
At the moment I am the only engineer working on this application, however more engineers may be assigned in the future. What would be the points to consider if you would to like to split up the project in smaller pieces or build one big project?
In addition: as far as I know it is not possible to 'share' a project in Architect over more than one developer. That votes in favor for splitting the project.
Disclaimer: I have not used Architect to build a project.
My thought on the matter is that if you are building an MVC project and you want Architect to manage your controllers and views you should keep all of it together. Especially if you have cross cutting communications between modules. However if you are 100% certain that your modules are completely standalone - meaning they have nothing to do with one another and might as well be separate apps ... (maybe they should?) ... then you could build them out separately and weave them back together after you are ready to ditch the architect. Remember its a one way street not an IDE. Bringing the modules together should just mean that the app.js now lists all of your controllers for all modules instead of just one for your module.