I work for a company that develops many websites to be used internally but many have parts that are public facing. It is important that all our sites look the same. In moving to dotnet core we found that we are no longer able to use a virtual directory to host the Layout page for our site.
We were storing our Layout page on a file share and referencing it in our projects with a virtual directory. This way if we needed to change the information in the footer, header, or some style/js we could upload a single change to the Layout page and that change would take place on all our sites.
I've tried researching any possible ways and the only thing I can come up with is a custom middleware that downloads the layout page from the file share and updates the current layout page if it is out of date.
.NET Core gives you the capability of creating Razor libraries. This would be a separate project where you can have shared views and reference it to the rest of your projects. You can find a simple implementation here.
You can choose one of these two options to do this.
Reference this project in each solution. Since your solutions directly reference the razor library, any change that is made in the common library will be reflected in every solution without the need of repacking and publish.
use dotnet pack to create a nuget in a shared location. While this option will require you to repack and publish each time, in some cases it would be a more organized solution. You can have a version setup. This means that when you update the shared razor project you will define a new version number. You can update this on each one of your solutions. This reduces the risk of a project breaking. Let's say you have 5 projects and 2 of them are not compatible with the latest update. In this case, you can update the 3 right away. The remaining 2 can be updated when you can spend time updating these projects to match the new requirements.
Related
Once an html page has been put together it starts to acquire dependencies on Angular and typescript.
This is not ideal for the web designer who really just wants to be able to view and modify their design. Usually this involves data elements too.
In our team the designer needs to be able to continue to work with html and stylesheets; they are not a separate contracted resource.
Is there a way to set up a project so that the web designer does not need to concern themselves with npm packages, Angular versions and data sources?
I have since had an idea...
As it happens I am a Linux user, the designer is a Mac user. I am wondering if it would be possible to create a project consisting of symlinks to html with typescript stubs.
A mock datasource might also be a viable solution.
I want to design more than 5 mobile Applications, but it took lots of time. So I want to set up all applications at one place, Is PowerApps suitable for it?
In PowerApps you can create multiple Apps, but each app is individual.
You can have in each App multiple pages/screens. You can show hide screens/pages based on what you want to show to whom.
I wish we could write code in simple JSON format, but the WYSIWG low-code format necessitates applying little bits of code to all sorts of places in the app. See "Where's the Code?".
You could technically create all common sections of the apps in a Component Library then create each PowerApp separately using the components, customizing per the app specs as needed. Then package the apps as a Solution so they reside under version control, etc.
But at this point...its easier for me to:
Create a DEV/PROD Env's (if you don't have them already)
Create a few simple components (header, footer, etc.)
Use these components to "outline" the app
Customize each app with data sources, collections, Galleries, etc.
Test
Then export from DEV env, import to PROD env
Make simple (yet CRITICAL!) config changes
Rinse and repeat
Disclaimer:
4yr PowerApps dev
Canvas Apps only
DataVerse averse
Web Developers!
How do you go about organizing your Github projects for your front-end and back-end?
For example, I have a python script that generates a JSON file that the front end JavaScript consumes to generate data on the pages.
Would you create one repository with two directories labeled front-end and back-end?
Or would you make two different repositories?
I'm interested in what developers do in the wild. Because up until now I found myself having a complete clone of my website in a directory on my desktop PC, and just pushing individual files via SFTP from there.
I'm getting to the point where I have enough *.old files that I want to implement version control so I can view much older states of code with Metadata like date and user that edited it.
The answer is yes. Make two different github projects.
Just Like Michael W has stated, "[...] this is highly opinionated". What I find to be the most common approach is to implement a single github project when still in development and especially when you're developing on your own. This is useful because you don't have to switch up between repositories and/or branches, which saves time.
Another common approach is to split them up. However this approach is only possible when both projects can run independent from one and other. In your case it's important to split the project logically. If the python project only generates JSON files and places them on a server location, then I would place that into it's own github project, because the main purpose is to generate files, so the python application can run on a server seperate from the frontend. If the webapp only consumes the JSON files through maybe a rest call or through a connection to a FTP, then also that can be placed within it's own project.
I have currently written an Angular 9 application, this consists of components and services.
The goal
I have in mind is to be able to override the existing html templates and/or the entire component using a plugin architecture.
I have been following the code located on GitHub here: https://github.com/apoprotsky/angular-plugin-architecture
The Problem
I am not able to use/import my services that deal with authentication, fetching data or dealing with forms etc.
Things I've Tried
Just importing it - doesn't work
Attempted to move all the relevant services to a separate module and load this into both the core app and the plugin, this works for the core app, but does not work for the plugin (it can't find it) - doesn't work
So, the question is, is what I'm trying to do at all possible - if so, what are the best methods for doing so, i feel like the github repo noted above is almost what I'm needing to achieve, but as stated, importing services etc do not work.
(my apologies for the non-specific wording of the question title, and for liberal use of öpen source" when I actually mean "project setup at SourceForge")
We have recently open sourced a 3D modeler we'd been selling for a couple of years, with the main goal of keeping the application alive. We setup shop at SourceForge.net, and are now working towards a process resulting in a steady flow of binary releases. So far, everything is swell.
However, besides the main application, we had also developed a couple of plugins (mainly for different import/export formats). Currently, these are still closed source, but we would like to open those up as well (3rd party plugin developers can take care of their own or donate and open the source). The question really is, should our plugins be hosted as a project on their own or not?
The options I see are:
Add the plugin sources into a subfolder of the SVN sources
Create a separate project for the set of plugins
Create a seperate project for each individual plugin
Which setup is the most practical and/or common, and how should I deal with the binaries?
When the application was still closed and commercial, it was kinda important that the plugin binaries could be updated seperately fom the main application, but now that everything is open and updated frequently, that's not so much of a big deal anymore. Also I'm not sure I want to bother contributing developers with a whole bunch of plugin sources they care nothing about as part of the main project.
Add the plugin sources into a subfolder of the SVN sources
I think that is a good idea if you don't have too many plugins. You could create a folder structure as shown at the end of my answer in order to manage plugins independently. But in this case you won't have fine control over SVN access.
The advantage is that you only have to maintain one project website (if you create one at all).
Create a separate project for the set of plugins
That's what Notepad++ does, for example. Their plugins are hosted on a separate SourceForge project. Having one download page full of plugins and another download page full of binary releases of your software improves readability. But don't forget to mention on the project web page that there's a separate plugin project.
It also has the advantage that you can manage the project web sites independently. For instance, you could put other users in charge of caring about the plugin site (if you find somebody who wants to maintain them).
Create a seperate project for each individual plugin
Not a good idea, maintenance will be harder this way, as you'll have multiple projects, repositories and project websites.
But it has an advantage though: You can be more fine-grained in granting people access to developing the plugins. For example, users A and B are allowed to work on plugin X, but not on plugin Y. With separate SF projects, this is easy to achieve. Same applies to the project web sites, of course.
So, as a conclusion, I would say that the more you care about SVN access rights and the more plugins you have, the more it makes sense to create one or more separate projects for your plugins.
Example SVN structure from #1:
/modeler
/trunk
/branches
/tags
/modeler-plugins
/plugin-x
/trunk
/branches
/tags
/plugin-y
/trunk
/branches
/tags