We're having a restructuring on our application and currently the idea is to break the codes into Core library codes + customized codes for our developer.
I'm thinking of the possibility to have a folder (i.e. 'custom') that is empty by default, and when the developer need to customize any codes either from existing asp pages or new pages, they just need to put them into the folder and it will work. Example:
Lets say core folder store the default asp pages.
core\customer\createCustomer.asp <-- the default page
And when the developer want to overwrite that page, he needs to copy that asp page to the custom folder, like
custom\customer\createCustomer.asp <-- modified asp page
The application will automatically load the one in the custom folder rather the one in the core folder.
Is this doable in C#?
This MSDN article explains how to use an IHttpModule implementation to intercept HTTP requests and perform custom actions (they point out logging, but since you're intercepting the request you might as well fetch some different content, such as your 'customized' code).
You can use a VirtualPathProvider to load a different file than the "actual requested one". This works well with IIS and caching for instance as well.
Basically you inherit the VirtualPathProvider and override the FileExists, GetFile, and DirectoryExists, GetDirectory methods (there's an example in the linked page). Then, in your AppInitialize, register the provider with
HostingEnvironment.RegisterVirtualPathProvider(sampleProvider);
By the way, don't forget to have a different (non-editable) page so the user can revert any changes that was made, in order to restore a potential misedit so to speak. I would probably have a simple version control system and use commit whenever the user made changes, and allow the user to revert to a previous changeset.
Related
I've got an application written in ASP .NET Core 3.1 that uses Razor pages to display various content.
I have a kind of project details view, where the details of the project are shown like image, description, some fields but also a list of files of the project.
The files of the project I collect using the Graph API (using credentials stored in Configuration/Azure Key Vault) and currently I list them out in a flat list. I store the list of files in my model (in a list with a custom object, to include metadata for the file)
I would like to show the files with folders, so the user only sees the top level folders and files when he opens the page. When he clicks on a folder, the folder should "open" and the user should now see the contents of the this folder (with an option to navigate one level up again).
Honestly, I am not quite sure how to start. I don't want to reload the whole page when the user clicks on a folder and as far as I know there is nothing like an Update Panel in ASP .Net Core that lets me only update parts of a page.
I also programmed some other Reat.JS applications, I know I could create a very dynamic react app to display those files but I am not sure if there is a good way to integrate such a react component in my ASP .NET Core app and also I don't know how I would pass the credentials to this component.
Hope someone can point me in the right direction and give me some tips.
Yes, there is no Update Panel in ASP.NET core MVC, but that doesn't mean you cannot update individual parts of the page. You can use a View Component to render just the content of a folder. The following is a list of key things you need to do to implement it:
Add a MVC action to your controller that returns View Component.
Enclose the folder content in a container div of known id.
Attach JavaScript event listeners to subfolders
When the user clicks one subfolder the event listener uses the fetch API to call the MVC action.
The event listener sets innerHtml property of the container div to the HTML returned by the MVC action
Attach event listeners to subfolders of recent loaded content.
This approach doesn't require any JavaScript framework or library. It can be implemented with plain vanilla JavaScript.
Probably you will want to add fetch and promise polyfills.
Unfortunately, this question is fairly broad and is likely to result in it being closed. (I didn't vote to close it). The challenge with this question is that there are so many different ways to handle this sort of programming problem.
Using ajax is one very common way to handle this. Which then brings us to javascript libraries, and there are a bunch of choices. You mentioned react. That is one good choice. If react feels too heavy for you then give my answer here a read with regard to Vue. VueJs is extremely lightweight and can easily be used on a single page or on a group of pages. Vue may be a great solution for you.
The main thing to know is that there is no "right" answer to your question which is why unfortunately it's not a great fit for StackOverflow. Here we prefer questions that have definitive answers. And this one has none.
I'm having a web application project which is running .NET 4.0. I've plenty of .aspx page and now I would like to add in a block of script code to all the .aspx page header, for example Google Analytics.
I know there is a solution to do is add in every single page, but I would like to know is there any other's way to do this instead modify every single .aspx page?
*My header is not runat server
I got an idea to do but not sure it's work or not.
Get the page class in Global.asax
Get the output stream from the page class.
Insert the Google Analytics code in the HTML header.
I couldn't get the Page.Response in the Global.asax as I tried in the Application_PostRequestHandlerExecute & also Application_EndRequest. Does anyone know is this work and how it's work?
Thanks.
Use master pages. This is the ASP.NET way of putting the same content on multiple pages without repeating yourself.
All of our aspx pages code-behind classes inherit from the same base class, which allows us to inject standard client side elements (controls, script, etc) into every page using a single point of control.
Our design was implemented before the advent of master pages, but while it could possibly be converted to a master-page design, we have found this implementation to be extremely flexible and responsive to changing needs.
For example, we have two completely separate application designs (different skin, some different behavior) that is based off of the same code base and page sets. We were able to dynamically swap out banners and other UI and script elements by simple modifications to the base class in order to support this without having to duplicate every page.
Unfortunately, if you want the script to be in the head element, you will need to ensure that they are all marked as runat=server.
Our base class itself inherits from Page, so it can intercept all of the page's events and act on them either instead of or in addition to the inheriting classes (we actually have internal overrideable methods that inheritors should use instead of the page events in order to ensure order of execution).
This is our (VB) code for adding script to the header (in the Page's LoadComplete method):
' sbscript is a stringbuilder that contains all of the javascript we want to place in the header
Me.Page.Header.Controls.Add(New LiteralControl(sbScript.ToString))
If it is not possible to change the heads to runat server, you could look into ClientScriptManager method RegisterClientScriptBlock which places the script at the top of the page.
You can create a basic page with the header with the custom code such as Google analytics and have the other pages inherit from that. It will facilitate two things:
1) In case you ever want to change the custom code you will only have to do it in one place
2) No repetitive code hence more maintainable
I am trying to do the same thing on a legacy app that we're trying to decommission. I need to display a popup on all the old pages to nag users to update their bookmarks to use the new sites, without forcing them to stop using the legacy site (yet). It is not worth the time to convert the site to run on a master page when I can just plop in a popup script, since this whole thing is getting retired soon. The main new site uses a master page, which obviously simplifies things there.
I have this line in a file that has some various constants in it.
Public Shared ReadOnly RetirementNagScript As String = "<Script Language='javascript'> alert('[app name] is being retired and will be shut down [in the near future]. Please update your bookmarks and references to the following URL: [some URL]'); </script>"
Then I am inserting it in Global.asax, in Application_PostAcquireRequestState:
Response.Write(Globals.RetirementNagScript)
Hopefully this is useful to you; I still need to be able to present a clickable URL to the user that way, on each page of the legacy site, and JS alert doesn't do that for me.
We have a sharepoint doucment library, the site consist media files(like images, word document, .psd file) and then we have a local CME (Alterian) which can be integrated to the SharePoint library in order to share the document library but the site needs to be on http// not an https//, coincidentally current sharepoint site is on https//, so we need to figure out a way/write a module which will work as a scheduled job (possibly using SPJobDefination class) and check on https// site for recently modified/added or deleted documents/records and then will copy them/normalize them to a dev site (hosted on http//, replica of the production https// site).
Experts please share your view's to proceed with a best approach to make this happen. (At an initial stage I'll have to copy over all the existing meta-data from the current https// site aswell)
Thanks a lot in advance for the time.
I would use event handlers on the https document library. Please see the SPItemEventReceiver.ItemAdded Method and SPItemEventReceiver.ItemUpdated Method.
So, every time you will add or modify an item, the code inside the methods is triggered. Inside the code, you may take the library document and copy it to the http site.
Regarding the existing items, you could write a simple console application which will copy the items from one list to the other.
Make sure that you make use of the SPListItem.SystemUpdate Method.
Also, the following excerpt from an answer to the question Moving Documents from library to library deletes version history, how do you retain it? could be helpful for starting:
(...) We can get the “SPFile” and the “SPFileVersion” objects from the
original library and add them to another library one by one. After
copying a file or version, get the original custom property form the
source file or version and use the “SPListItem.SystemUpdate(false)”
method to update the target file or version. This workaround can
persist most of the properties except the “modified time” or “modified
by” field. (...)
I currently have an ASP.NET web application that is serving multiple clients from a single codebase. We use URL rewriting to detect which client is being served (pretty much a virtual vdir) and that drives which master page/themes/module version to run.
Right now, each client can have a different version of a module or the default module. A module may consist of a catalog (grid) of data with various links to other modules, or it can be a chart generation module with options for which data is pulled. The modules need to be themed and localized...
Right now, we make ascx controls (/modulename/clientid.ascx) that are a part of the website's solution. If we haven't registered a control for a client, the default is used. To publish an update to any module a full publish must take place. This can be an issue if a different client has work that isn't ready to be published. For the rewrite I'd like to address this. I'm just not sure what approach to take for this. Can WCF be used here? Maybe add-ins? Each client's implementation is its own dll?
Thanks
you might want to have a look at making the client controls proper skins that just style/load the rest of the control.
so possiblly a base control that all the client controls load (per module) then the client controls are simply markup, this would mean you only need to change the markup and not to code (so you dont have to build everytime)
"To publish an update to any module a full publish must take place" - this is a problem you need to address in your architecture.
Look to de-couple your modules from the rest of your code.
Putting your modules in their own assemblies may be the key to this, as you touch on in your question. This could be addressed by writing your own Server Controls rather than User Controls as Server Controls don't require an ascx file.
I have a web site that serves only one page from the root. The page (call it stuff.htm) is generated by a custom handler, and doesn't physically live on disk.
I'd like stuff.htm to be the default doc for the site, but the standard configuration method of making it the default doc fails since the regular ASP.Net DirectoryListingModule is trying to do a Server.Execute of the file. (At least, that's what I can infer is happening.)
I know I can write code through a default.aspx that does what I need, but I want to avoid writing code for this. Any known configuration tricks to supersede the default handler behavior without having to override the default handling behavior?
Is ASP.NET set to handle the file extension you are trying to serve? If so I would expect it to work correctly; otherwise here are some "cheap and dirty" answers.
The "cheap and dirty" answer is to create an empty file named stuff.htm at the root, set it as the default page, and then ensure that ASP.NET is mapped to handle the .htm file extension (or whatever you are actually using).
The second "cheap and dirty" answer is to create a default.htm page and then set it up as a redirect to stuff.htm.