This sounds like a "why would you do that?" sort of question, but here goes..
I have a very simple ASP.NET page which simply renders out a one column grid of about 10 rows with paging.
At the moment, I need (due to some technical restrictions) to essentially host the ASP.NET page within an IFRAME on a basic HTML page. It works of course, although I wonder if there is a better way?
For some reason I am thinking something like silverlight (which I might end up using) being a container.. or some other ActiveX type control..
Hope this explains enough?
Thanks in advance!
You're right, this is pretty much a "why would you do that" type of thing. However, we all know that you don't always have control over what you would like to do thanks to managers who don't know jack about developing websites, etc :) as I've been in a similar position and been forced to do almost exactly the same thing.
Anyways, I believe the way you are doing it is about the simplest way to do it. The only thing you might want to keep an eye on (I don't know if you are running from separate domains, as the question doesn't specify) is cross-domain scripting. For example, if your ASP.NET page is at www.myaspdomain.com and your HTML page is at www.myhtmldomain.com, cross-domain scripting, or scripting between the IFRAME and the ASP.NET page can cause some interesting bugs (features?) because of the security holes that such scripting opens up and has thus mostly been blocked nowadays.
You might be able to use XmlHttpRequest to fetch the contents on ASP.NET page to an HTML element.
Related
Not sure if this belongs in community wiki...
Can somebody give some general guidelines on how to successfully build an ASP.NET site that isn't dependent on JavaScript? My understanding is that I should build a functional site initially without JavaScript, and use it to enhance the user experience. That is easier said than done... how can I make sure my site works without JavaScript short of disabling JavaScript and trying it? Or is this something that comes with experience?
Try ASP.NET MVC! sure most of the examples use JavaScript for the AJAX functionality, but it's easy to build a fully functioning site that doesn't use JavaScript.
Since ASP.NET MVC doesn't use server controls with all their embedded JavaScript, it's a great way to build a site with very minimal and lightweight HTML, while still writting your data access and business logic in C#, VB.NET, or any other .NET language.
I've built working ASP.Net sites with little or no JavaScript, so it's definitely possible (just a royal pain.) The trick, and this sounds silly, is to use as few <ASP:> type tags as possible. Those all spawn various levels of JavaScript. Regular old-school HTML elements work just fine with no scripting.
So, on the extreme end, you write, say, your form using all plain-vanilla HTML elements, and then you have that form submit point at another page that accepts the form submit and hands it off to your server-side scripting.
To put it another way, pretend that all you get with ASP.NET is a snazzy server-side programming language and you're writing HTML in 1998.
Now, having done this, I can tell you that what this ends up as is a classic ASP webpage with cleaner programming syntax. ;) Most of the features that make ASP.NET "better" than classic ASP hang on JavaScript, so writing a JavaScript-free ASP.NET system is an exercise in shooting oneself in the foot repeatedly.
However, the one thing you should absolutely do is make sure the first page or two do work without JavaScript. Unlike 10 years ago you can safely assume that any browser hitting your page has JavaScript, and unlike about 8 years ago, your visitors probably don't have JavaScript turned off for speed reasons, but they very well might have something like the NoScript plugin for Firefox dialed all the way to 11. So, your first couple of pages need to work well enough to a) tell the new visitor that they need JavaScript, and b) still look and work good enough to make it look like adding your site to the white list is worth it. (In my experience, most people get the first one done, but in such as way as to totally drop the ball on the second. To put it another way - if your super fancy web 2.0 mega site starts looking like craigslist if noScript is fired up, I'm probably not going to bother letting you run scripts on my machine.)
If you want to use many of the ASP.NET controls (i.e. the DataGridView), ASP.NET pages are generated with lots of JavaScript in order to handle the events on the controls (i.e. selecting a row in the DataGridView). I think you're going to lose so much of ASP.NET that trying to have ASP.NET work without JavaScript enabled is impractical.
Disabling Javascript is the best way to test how a web site performs with out it. Good news, IE8's developer tools provide a quick and easy way to do just that. Now, having said that, often times the only thing that you can do is put up a message with a noscript tag to the effect that your site requires javascript for best function.
Many ASP.NET functionalities & controls won't work when JavaScript has been disabled. Think of LinkButton's onclick event which contains a call to a JavaScript function.
LinkButton is just an example. But there are many other things too.
If your concern is with JavaScript being disabled in user's browser then you can check for that and handle your site accordingly.
If you do decide to build the site without JavaScript then you will end up building a somewhat static web site. If your need is just to build a static website then you can go on with this approach.
Write everything with basic html forms and css, and then you will know that it works without javascript.
Once you are happy with it, then look at unobtrusive javascript, so you can modify the way the application works when javascript is enabled.
Last time I looked at some stats about this around 1% disable JavaScript, so why spend hours and hours on this when what you should do is show a message telling the user that your site requires javascript.
Use your time to be productive instead of trying to write around perceived limitations.
Our organization has dedicated designers who design the page and cut it up in Dreamweaver. That's worked well in the past with ASP and PHP sites. Now we're trying to make it work with .NET, but are struggling because of the structure of a project in ASP.NET. How does everybody collaborate with developers? The specific points I am looking for are:
-Transferring Dreamweaver content to Visual Studio
-Changing HTML inputs to server controls
-Giving designer access to finished Visual Studio product so they can tweak layout
Thanks!
Obviously, there will be a slight learning curve for your designers. But with that said, I have worked quite often with designers (none of whom used Dreamweaver, btw, so that may be part of the problem) on asp.net sites. Usually, they will create the HTML exactly how they want it on the server like a static HTML page, then I will go in and replace form fields manually with asp.net controls.
On an aside, I have found that I have the best chance of matching the design using controls that spit out the least HTML, such as Repeaters instead of DataGrids.
Once the site is up on the server and programmed, they can go back in an tweak things if need be.
Also, just like we have to adapt to them a bit (making our server controls spit out html how they like it) they also have to adapt to us a bit and not rely as heavily on id attributes in their stylesheets as some items id attributes will be controlled by hte .net runtime since they are controls.
MOre often than not, a designer new to asp.net will feel very threatened by this new way of doing things, specially with user controls instad of include files, but its really not that different than classic asp/php development is.
The key to the solution of all your problems in this matter is quite simple, and yet so hard to fulfill: it's usually called semantic markup. If you can make sure that the designers to start with make their html semantic, and that the .Net programmers keep rendering the same markup but with their server controls where needed, the tweaking won't be a problem - the markup is the same.
So what is semantic html, then? you may ask. Well, it's not always as simple as one would like it to be. A good start is to make every page pass XHTML validation.
In my experience, designer-created HTML almost always needs to be at least refactored, if not rewritten. So, open a browser with the original HTML on the left, and try to match it as closely as possible in VS on the right screen.
Giving designers access to ASP markup is not a good idea, imho. Too much can go wrong if you only understand half of the tags you are manipulating.
How about using one of Microsoft Expressions line of products? I've heard they are to .NET what dreamweaver is to PHP/ASP.
I'm learning ASP.NET using a great Sitepoint book, and I'm also learning more about CSS. I'm undecided on how useful Master Pages are. Could someone let me know whether the real world use mater pages - and if they don't what do they do?
Cheers
Mike
Yes, we absolutely use them.
Typically you will use master pages to handle your header, footer and navigation sections that are consistent through-out all the pages in your website.
This follows the DRY principle of not having to repeat yourself when creating new web forms.
MasterPages are the best feature that came with ASP.NET 2.0.
I use them whenever I can. They simplify your maintenance and management on a website. With a one change you can change whole site.
I always use master pages. It helps keep the code for each page less cluttered, and as previously stated, it lessens the need to repeat yourself.
Speaking of CSS, I use CSS to style the master pages, and set text formating "rules", while I usually end up styling graphics in each individual aspx/ascx-file. I find this less confusing, as you'll otherwise end up with one massive CSS-file - which is hard to keep structured - or a myriad of CSS-files - which often get hard to keep track of.
We use Masterpages for many of our applications and find them a benefit but I think your right to question how useful they are.
For our applications that have a large number of pages it's great to be able to extract a lot of the style information to one place. I know it's possible with include files etc but as Masterpages are the main method for Visual Studio it's obviously integrated very well and easy to use.
The biggest benefit for me is that I tend to use the same Masterpage across many applications thus giving them all the same look and feel. Again I know this can be achieved in other ways but it's Visual Studio integration makes it the easiest for us.
I think the best way for you to decide is to try them and try an alternative method as well. Pick your favorite and then let us all know!
Master pages are absolutley crucial to any ASP.Net application. They are the building blocks for your site.
And if you ever start looking at SharePoint they are the underpinning of all customisation and branding.
Why would you think otherwise? I am interested to know why you might not have thought them as useful.
I've had a solution delivered without master pages, and its a real pain trying to change the layout of the page, as each page has to be changed individually.
I've never created a web page and I'm just learning ASP.NET now and all the examples I see are mostly with filling out forms etc. So I'm wondering if the lively, colorful, and snazzy web sites can be done with ASP.NET. I have also been playing with a trial of Expression Web. It seems to be for the "fancier" side of things. Are the two sides of the web mutually exclusive or can an ASP.NET page be just as colorful? Keep in mind I'm new to doing anything on the web.
Thanks for your help?
Yes, you can make an ASP.NET page look just like a static web page. The look and feel of a web page is done completely on the client side, using HTML, Javascript and CSS. ASP.NET lets you use all of these things, but it provides the ability to generate output to the page on the server side before sending it to the client's browser. Once it gets to the browser, the HTML, Javascript and CSS will apply just as if the client was loading a static page.
Absolutely yes!
You may be confused with the tutorials which are focused on teaching backside technology and poor on page design. Isn't microsoft.com colourful enough?
Asp .Net just outputs html.
ASP.NET is simply a web application framework. What is sent to the browser is *usually** HTML, so anything that you can do with a static HTML page, you can do with ASP.NET.
In my personal experience, I have had better luck with producing "lively" pages using ASP.NET MVC, since I have better control over the markup, and I don't have to contend with ViewState or munged control IDs. Subjectively, the pages feel less sluggish than those of ASP.NET, and I can use JQuery to improve the user experience.
Yes you can, just do not use Web Controls. I have written several Blogs on this so far this year. http://professionalaspnet.com/archive/tags/Thin+ASP/default.aspx
Ultimately, html is sent to the browser irrespective of the server side technology, so question is a bit awkward.
But for aesthetics side, asp.net provides features called master pages, themes, skins. By providing these it goes beyond css.
ASP.NET can be used to produce very lively and colourful pages, but you need to understand how to create the pizzaz. Mostly that's going to be media and javascript. For that, you need to understand HTML, and then what the ASP.NET Server controls render as in HTML so that you can control and manipulate it in your javascript more easily.
The reason that ASP.NET tutorials feature data and forms is that the need to manage data (and dynamic content deriving from it) is what makes people use ASP.NET rather than static html.
When designing a ASP.net WebForm application what are some important steps to take (or hacks if you like to use the term) to ensure the best possible performance (in terms of speed, stability, and scalability)?
Here's a good Best Practices written by microsoft. Chapter 6 is specific to ASP.NET, but the whole document is .NET in general.
http://msdn.microsoft.com/en-us/library/ms998530.aspx
You've got a ton of material, directly from Microsoft here.
Also a checklist is available if you want condensed information.
Just a couple, in addition to the good advice already given,
Don't put every single page in a webform, not everything needs it - The default behaviour from VS is to give you a master page that wraps a form around everything, and a lot of people seem to stick with that. In my experience, some controls can render 30% faster outside of a webform, so if you're just parsing a querystring then reading something from a database, leave the form at home if you can. Even getting your navigation out of the form will help.
Don't use a server control when plain old HTML will do - does it really require a asp:linkbutton or asp:hyperlink just to go to the FAQ page etc. Plain hyperlinks work just fine in asp.net, but some people seem to get stuck on the idea of using runat="server" for everything.
There is a phenominal book on this subject by one of the Yahoo guys, Steve Souders. It taught me a lot.
Or you can just watch this video. It's a high level overview of the same information - you can pick up a lot in 45 minutes by watching this.
NOTE: This content is not WebForms-specific. It's general best practices for the web, and it is what you need if you are trying to roll out a high performance website.
Big # 1 tip: turn off viewstate in the web.config. That should have been the default, if you need it for a control turn it on on a control by control basis.
My other piece of advice is stay the hell away from *view controls. Use repeaters and find a good 3rd party grid control. The really "magical" controls that ship with asp tend to be perf hogs, and in general just not a good idea anyways (with the possible exception of ListView)
1 - Turn on content compression on iis
2 - Cache everything you can
This will do for the majority of webapps out there.
I am not sure about content compression when the content involves html with js doing ajax stuff. Sometimes the blocks of data exchanged through ajax are small and in this case (and if that is considered content) compression often hurts instead of helping. For example, a four bytes block of data produces a compressed block of 100+ bytes.