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.
Related
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.
With ASP.net I am familiar with creating a master page and then being able to set that master page for a .aspx file.
With one of our sites where I work we are given ftp access to edit static html pages. Within these html pages are a few asp tags, specifically a page directive with title, language and masterpagefile attributes, and a few content tags with id, contentplaceholderid and runat attributes.
My question is how are they doing this? If I were to add a master page in visual studio for my own project I am unable to pick a master page for .html files. Are they somehow building/overwriting a .aspx file after upload? If I go to the website the url will show a .html extension.
Within these html pages are a few asp tags, specifically a page directive with title, language and masterpagefile attributes, and a few content tags with id, contentplaceholderid and runat attributes.
Then the host is processing these .html files through the ASP.NET runtime before serving them. At a technical level ASP.NET pages don't need to have the .aspx file extension, that's just by convention. The web server can be configured to process any files as ASP.NET pages.
If you look through the configuration of IIS for example (and the specifics of that will vary wildly with IIS versions), you might find something like (and this may be quite dated, I haven't had to look under the hood in IIS for years) a mapping for .aspx files to aspnet_isapi.dll. That same configuration can also be changed to also map .html files to aspnet_isapi.dll, which would process them the same way.
This isn't common practice not only because of convention but also because server-side processing adds overhead and is less performant than serving a static file directly from the web server. Since .html files traditionally have static content, it's a lot faster to let IIS serve them directly than to process them through the ASP.NET engine. It's possible, and the host in question seems to be doing exactly that, it's just uncommon for these reasons.
In Visual Studio you can change the settings to serve Dynamic content.
In Application Designer, you must specify whether an ASP.NET application exposes dynamic or static content. Dynamic content specifies that a script processor such as ASP.NET is required to run the application or any Web services associated with the application. Static content specifies that no script processor is required, for example, to run the application or to display HTML.
http://msdn.microsoft.com/en-us/library/ms242474(v=vs.90).aspx
I'm not new to programming but am new to Visual Studio, MVC, C#, ASP.NET, and EXT.NET, i.e. all of the tools I am trying to use.
I am trying to create an Ext.Net 2.0 MVC4 project and was given a similar (in functionality) non-MVC project for reference.
I see that this non-MVC project has .aspx and .aspx.cs files. It seems like the .aspx file basically maps to the "View" in MVC that I want to make... And the .aspx.cs file has the functions that relate to the .aspx file - so is that like the "Controller"? Though the .aspx file also has some functions that seem to not be entirely view-related...
Could someone give me a quick overview or a place to start with this?
ASPX files usually will have the UI and will which is usually HTML tags, some ASP.NET server control embed code (which ultimately produce some HTML markups). ASPX.CS file (usually called "code-behind") will have server-side coding in C#.
If needed, I would relate ASPX page to View and ASPX.CS to Controller action methods.
You have to remember that in webforms, there are ASP.NET controls we will be using in the ASPX file to render some HTML. Examples are TextBox, DataGrid, etc. In MVC, there is nothing called Server control. The View will be pure, handwritten HTML.
If needed, you can create a Hybrid project which is a combination of MVC and webforms. Scott has a post explaining about it here.
No ViewState in MVC :)
When switching from ASP.NET Webforms to MVC, One important thing you have to understand is that MVC architecture tries to stick with the truth that HTTP is stateless. There is no viewstate available in MVC. So you need to make sure that you are repopulating the data in every HTTP Request, as needed. Folks usually run into problems in loading DropDownlist in MVC. There are a lot of answers here in SO about how to handle dropdown lists on postback (when form is posted).
I suggest that you look into some beginner-level tutorials on ASP.NET MVC and start building your app step-by-step, and if you run into any issues, post a (new) question with relevant details.
Good luck, and welcome to the wonderful world of MVC. :)
It sounds like you haven't created an MVC project, but rather a WebForms project.
The *.aspx files are the markup and the *.aspx.cs files are the code-behind files. Code-behind files handle the .NET code for any server-side controls in the *.aspx files.
Checkout Wikipedia's document on ASP.NET, http://en.wikipedia.org/wiki/ASP.NET.
It states:
Web forms are contained in files with a ".aspx" extension; these files
typically contain static (X)HTML markup, as well as markup defining
server-side Web Controls and User Controls where the developers place
all the rc content for the Web page.
Additionally, dynamic code which runs on the server can be placed in a
page within a block <% -- dynamic code -- %>, which is similar to
other Web development technologies such as PHP, JSP, and ASP. With
ASP.NET Framework 2.0, Microsoft introduced a new code-behind model
which allows static text to remain on the .aspx page, while dynamic
code remains in an .aspx.vb or .aspx.cs or .aspx.fs file (depending on
the programming language used).
The .cs file names .aspx.cs is the code behind that goes with .aspx, which generally holds the html, css, javascript and other client side controls.
Generally, dynamic code (C# in this case because of the .cs on the file name) goes in the .cs file as a "good practice" to keep dynamic code and static html separated. Another reason for this abstraction is that the .aspx.cs code is run server side, while the .aspx file is compiled on the server and is then served to the web client requesting it.
Additionally, for MVC, I would suggest using a different view model, specifically Razor, which uses .cshtml files instead of the .aspx.cs and .aspx because they are easier to follow. The reason for the change in MVC is that MVC uses the MVC pattern to abstract layers of code so that .aspx and .aspxcs are not as needed. From a personal experience, I have used both Razor and Webforms (.aspx/.aspx.cs) view models with MVC and I find Razor to be much easier to code/maintain and use.
The aspx file contains your page markup. It's automatically converted into code by ASP.NET.
The cs file contains the code behind your page (initialization, event handlers, etc.). You have to write that code yourself.
These two files are related with the inheritance and he Inherits attribute of the #Page directive associates the page markup to the code behind
.aspx is your markup file. Contains things such as HTML, CSS, JavaScript, and ASP markup.
this .cs file is referred to as a codebehind file. This is where you do thing that may not be available or u are not comfortable doing in scripting languages. Generally aspx is run on the client side while the code behind is executed on the server.
Is the best approach to loading javascript files to put them in an IFrame and then embed the same in asp.net pages? I have read somewhere that this will help to boost page-loading times.
Best is to put script references at the bottom of the page. This ensures that all content is loaded before the scripts. Don't use the iFrame unless needed.
When looking at page load times, it depends on where your code is stored. If it is in the html then it will be reloaded each time the page is loaded. If you move it out to a js file, it will be loaded the first time and cached after that so then you shouldnt have a problem with affecting the load times.
You can use jQuery's $(document).ready to make sure that all the elements are loaded before running any code.
Don't go for the iframe approach. Put the scripts as far away at the bottom of your html as possible and your css as high as possible. Also try to go for unobtrusive javascript if possible. jQuery's great at this so you surely want to take a look into this. The benefit of jQuery is that it's also put on CDN servers which also speeds up performance.
I found these guidelines to be a great help when I was upgrading the performance of one of my former projects at a client: Best Practices for Speeding Up Your Web Site.
Some great tools are also Firebug in combination with YSlow.
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!