I have some pre-compiled html content which I want to include in my View like:
#*View Start*#
Some precompiled html
Some view content
Some precompiled html
Some view content
Some precompiled html
#*View End*#
I have already thought of some ways but each of them has some GREAT downsides that I don't want to use it. these are the ways I have thought of:
Although these html codes are pre-compiled with fixed content they may change time to time (let say weekly) so can not be included in view itself
They're rather big in size so I don't think having them in database would be wise (would increase database size and data-bandwith)
Having them in html files and writing them into view using C# functions something like #File.ReadAllText("page-customized-head.html") and this would be slow and would make hard disk busier than it should.
I want to know if anybody can suggest a better solution or a way to improve the above solutions.
Edit:
I had put aside solutions like ajax, as in this situation was not suitable for my design. After #Hadee's comment I noticed that my description is not complete, so I'm adding some more description.
These content files can be unique for different pages of different users as user can customize css, js. add - edit remove html elements. So each user may have several pages that each page may have several different "Pre-Compiled" section.
As these content may be the head section of the page, may contain css, js (that following content may rely on it), ... ajax is not suitable in here.
And as for partial views, I don't see any different between them and having the content written into html file. Actually I think html file and #File.ReadAllText("page-customized-head.html") would be faster, as unlike .cshtml it does not need compiling.
Related
Background: I'm trying to make an extremely light news sort of...thing that relies entirely on hard code ASPX documents (not my decision). What I would like to do is create a bit of dynamic updating by having the main news page pull the latest ASPX file from a folder and get its "TopContent" section on the main page. How would I best be able to do that? I'm stuck with ASP.NET 2.0 on this project as well.
So I didn't quite transclude ASPX documents, but I found a way to get this to work by having XML files with the data pieces I needed and just using that. No problem.
In detailed: An XML file containing the title, the top content and the main content and then using a URL argument to figure out which file to open.
I originally come from PHP and I have just started with ASP/.NET. I am aware that a direct equivalent of include("filename.php"); does not exist, but that's not exactly what I want to achieve.
I am attempting to create a header file which I can use on every page. I have read from many sources that making a user control is the solution. After creating all of the necessary code to make this work, I arrived at a point where the actual element on the page isn't actually created at the point when I call .InnerHtml. For example:
breadcrumbContainer.InnerHtml = "testing text";
The above code does not work when called within my file which is called header.ascx.cs even though there is a div on the page with runat="server" and the correct ID.
I am trying to find out if there is an easier way to resolve this problem. I have been told that I should avoid masterpages (even though I don't know if they are relevant in this situation). Should I create some sort of method which creates the html for the header, this way I can easily call it on every page? Are there any other solutions I haven't thought of?
If there are any good articles which clearly explain this problem, I would love the links. I have literally searched hundreds of pages on the web and found nothing that is giving me a clear understanding of how to resolve this problem.
Master pages can be relevant and very helpful in this case. Check out them out.!
When someone says "don't do something" always ask why. Do not take such advice at face value. That's exactly how phantom fears are spread and thousands of developers end of treating some programmer's pet peeve as an an absolute rule! Besides, asking "why?" will strengthen your own as well as the more senior developer's understanding of the issue at hand.
From the link:
ASP.NET master pages allow you to create a consistent layout for the
pages in your application. A single master page defines the look and
feel and standard behavior that you want for all of the pages (or a
group of pages) in your application. You can then create individual
content pages that contain the content you want to display. When users
request the content pages, they merge with the master page to produce
output that combines the layout of the master page with the content
from the content page.
I am creating a website in .aspx, and while adding more pages I saw that I can choose for an .aspx-extension and for a .html-extension.
I am a bit confused at the moment. Normally I am using always the .aspx one, but what is the difference between them and which of them do you guys prefer me to use?
Thank you very much.
This is the biggest challenge for the beginners. Aspx pages and asp.net webservercontrols are like machines that spit out html. if you want a logic to spit html on the page according to that logic then use .aspx or Webservercontrols on that page. if you don't have very serious decisions to make programmatically and need straight forward html that does not change based on some events then use .html pages. But if you are on something like asp.net then it means you may have to make decisions based on data from the server so in that case .aspx would be requirement than an option.
An HTML file can only contain static content (it can not contain any server side code), it will not be processed by the ASP.NET pipeline.
So normally you should always use aspx files in an ASP.NET app, except if you have a page which only has to contain static HTML, that way you might save some performance, because IIS can directly serve that file without running it through the whole pipeline.
.htm/l files are generally used for static markup, but they can be .NET-enabled also (using configuration options). That is to say, other extensions can be compiled and run through the ASP.NET ISAPI handler to be pages that have code-behind and managed controls and "do stuff" server-side.
I guess it's preference, so you could decide to use .htm/l for server-handled pages and .aspx for handled pages. I personally don't find this option appealing and have to deal with, at least weekly, an .htm/l page that didn't need any .NET stuff but now does. It doesn't make sense to me to mix up the files like this - the effort for IIS should be negligible, particularly for .aspx pages that contain only static content. It's much less effort than having to wonder about changing file names (and therefore URLs or rewrites) or setting global configuration options to handle certain extensions because modifications were needed.
I've a question related to dynamic code generation (html) with C# based on a template. The user sets all options (e.g. whether or not a <div> should be displayed, whether or not an image in the template should change by a specific date,...) and provides the content (text, images) needed for code generation. The generated code is needed for a WIFI hotspot site.
The template consists of HTML, CSS and JavaScript which gets extended and modified by the user-defined settings at runtime. I also think of providing "meta settings" in the template to define, whether or not some options CAN be disabled set or not.
My major problem:
How to define the template to dynamically extend the template code easily? For example, if a user option is enabled at runtime, I'm in need to add JavaScript code on top and HTML code below another (specific) place. Another example is to hide content (a defined ) when another option is disabled...
I'm not sure what's the best practice to handle that requirement. Maybe HTML elements with id attribute can help eliminate some of the problems. But with JavaScript I'm not sure. Maybe the template needs to be a XML which creates the final HTML at runtime? Any idea?
Has anyone an idea how to handle that?
UPDATE/INFO:
The project is written in pure C# - without any ASP.NET. It is a desktop project working with HTML files and GENERATING HTML files (as an output).
I suppose you can use ASP.NET MVC Razor view engine to render an html to a file with the help of this question. With Razor you will get the support of dynamic view (aka template) changes, rich template syntax etc. Everything you can do when create a web site. Just render the html to a file not a response body.
One of my friends is working on having a good solution to generate aspx pages, out of html pages generated from a legacy asp application.
The idea is to run the legacy app, capture html output, clean the html using some tool (say HtmlTidy) and parse it/transform it to aspx, (using Xslt or a custom tool) so that existing html elements, divs, images, styles etc gets converted neatly to an aspx page (too much ;) ).
Any existing tools/scripts/utilities to do the same?
Here's what you do.
Define what the legacy app is supposed to do. Write down the scenarios of getting pages, posting forms, navigating, etc.
Write unit test-like scripts for the various scenarios.
Use the Python HTTP client library to exercise the legacy app in your various scripts.
If your scripts work, you (a) actually understand the legacy app, (b) can make it do the various things it's supposed to do, and (c) you can reliably capture the HTML response pages.
Update your scripts to capture the HTML responses.
You have the pages. Now you can think about what you need for your ASPX pages.
Edit the HTML by hand to make it into ASPX.
Write something that uses Beautiful Soup to massage the HTML into a form suitable for ASPX. This might be some replacement of text or tags with <asp:... tags.
Create some other, more useful data structure out of the HTML -- one that reflects the structure and meaning of the pages, not just the HTML tags. Generate the ASPX pages from that more useful structure.
Just found HTML agility pack to be useful enough, as they understand C# better than python.
I know this is an old question, but in a similar situation (50k+ legacy ASP pages that need to display in a .NET framework), I did the following.
Created a rewrite engine (HttpModule) which catches all incoming requests and looks for anything that is from the old site.
(in a separate class - keep things organized!) use WebClient or HttpRequest, etc to open a connection to the old server and download the rendered HTML.
Use the HTML agility toolkit (very slick) to extract the content that I'm interested in - in our case, this is always inside if a div with the class "bdy".
Throw this into a cache - a SQL table in this example.
Each hit checks the cache and either a)retrieves the page and builds the cache entry, or b) just gets the page from the cache.
An aspx page built specifically for displaying legacy content receives the rewrite request and displays the relevant content from the legacy page inside of an asp literal control.
The cache is there for performance - since the first request for a given page has a minimum of two hits - one from the browser to the new server, one from the new server to the old server - I store cachable data on the new server so that subsequent requests don't have to go back to the old server. We also cache images, css, scripts, etc.
It gets messy when you have to handle forms, cookies, etc, but these can all be stored in your cache and passed through to the old server with each request if necessary. I also store content expiration dates and other headers that I get back from the legacy server and am sure to pass those back to the browser when rendering the cached page. Just remember to take as content-agnostic an approach as possible. You're effectively building an in-page web proxy that lets IIS render old ASP the way it wants, and manipulating the output.
Works very well - I have all of the old pages working seamlessly within our ASP.NET app. This saved us a solid year of development time that would have been required if we had to touch every legacy asp page.
Good luck!