When I generate code using T4 templates in Visual Studio 2010, I get the following error for each of my asp controls when I try to compile:
Control "ddState" is missing required attribute "showat".
I have never gotten this error in previous versions of .NET. Further, I don't get this error when I manually construct my pages either by dragging/dropping, nor do I get it when I type out the control text myself. When I generate code, I have to manually add showat="client" to my tag for the compiler to be happy. It was my understanding that I never had to explicitly specify this tag. The following:
<asp:dropdownlist id="ddState" runat="server" showat="client" />
solves the problem. Why do I have to add this to generated code but not other times?
(It's a VS-2010 webforms project, using VB, in case that makes a difference.)
Apparently .NET 5 or another one of those super service packs is going to allow something called targeted rendering. It was originally intended for use just in the context of webforms, but I've heard recently there will be some fancy way to use it in MVC (using some helper classes) and in services using WCF. It will work well with Dynamic Data but is very loosely coupled with it; you can use one or the other completely independently. If you configure your dynamic data with certain tags you can have it constructed on the client, etc.
For now, just put showat="client" in all your tags, and all is good. That's supposed to be the implicit default, but I've heard of cases where the IDE seems to require it. In the future, showat="client" will be the safest setting anyway, giving the expected behavior in 99.9% of cases.
This is required in VB, but not C#, which is why it seems to not be necessary sometimes. To be more specific, the C# compiler puts the equivalent of showat=client into the IL automatically, unless you specify a showat target other than client.
"showat='client'" should currently have little effect on your coding. It's main purpose is for future WCF output targeting, which they will want to be backward compatible. For now, the only possible value is "client", but in the future there will be other possible values that will allow pre-rendering of cached values, and apparently "pushing" output to services. The example I saw at the last code camp was where you could push to a service at (probably) the same site as well as to the client machine, for logging/debugging purposes. You'd have something like (to use your example):
<asp:dropdownlist id="ddlCP" runat="server" showat="client, logService" />
. . . and then the rendering would go to your log file. Or, to your session provider (if you've got multiple web servers and are implementing a shared session provider), etc. I think logService above would have to be defined in the web.config or something.
Check to see if VB does anything in the web form designer page when you use the IDE to add the control. I'm not sure how VB inserts the implicit tag. But that would be something the T4 template would miss, just a thought...
Agreed that my VS2010 solves this issue for you. Then you can remove the tags completely. I would suggest getting the upgrade. It's well work the $599 upgrade cost. Otherwise, look to add the showat="client" in all the tags. I think that Rising Star got that one right, although I haven't tested it yet.
Related
I'm feeling a bit lost with my question about HTML5 code generation, and despite having put some efforts into my research I don't really feel much wiser.
I use VS2010 for the creation of ASP.NET pages, and I do know that there is an (unofficial) "Web Standards Update" for VS2010 SP1. Using this update I can change the settings of the "Target Schema for Validation" in the ASPX editor window to HTML5. The new elements / tags and semantics are then available via Intellisense, and I can nicely code away manually using all the fancy new stuff.
What I don't understand is how to get something like the ASP.NET controls to generate HTML5 code (where it makes sense). Is this at all possible or am I completely going in the wrong direction here? I would have expected that I do not have to "hand code" HTML5 as long as I use the existing controls (which tend to generate a lot of JavaScript in the background when the page is delivered to the client's browser).
Thanks in advance for a clarifying answer
G.
Some controls generate slightly different dialects of HTML based on the particular User-Agent. However, not all of them know about HTML 5 yet, and there's no specific property to enable HTML 5 generation, just as there isn't a property to enable other dialects of HTML.
If you want to generate HTML 5, you can do one of three things:
Create a new control that overrides the existing one, and either use it directly or replace the original with it everywhere in your app with tag mapping
Create a control adapter and modify the control's output as it's generated
Create a custom control
The controls you are referring in ASP.NET are what is commonly known as "webforms". They are basically server side controls that generates the javascript code needed to postback the data to the server, mantain the state of the controls between postbacks, and stuff like that. As you said, those controls generate too much code and a excessive number of roundtrips to the server, so it is not very recommended to use webforms.
HTML5 is mainly client side, so it has very little to do with the webforms server controls. It's a different approach than the old ASP.NET webforms. Because of this, ASP.NET is including on its newer versions the MVC framework, the razor engine, JQuery and another javascriprt libraries. MVC includes some helper classes and templates that helps you generating the client code, and many other features to support HTML5 enabled webs. So, I would recommend to start reading about it.
Anyway, now that jquery is fully integrated in Visual Studio, javascript coding is not so difficult.
This is a simple question, NikhilK answered to this question:
"Script# doesn't support ASP.NET Ajax anymore"
Does that mean that we can't use Asp.net UpdatePanels (which need a ScriptManager) in the same page where we load mscorlib.js? Even if mscorlib is manipulating DOM elements that are not inside the updatepanel?
When I mentioned asp.net ajax is not supported, it is primarily a two-fold statement:
MSAjax assemblies allowing you to program against the msajax scripts are no longer included.
There was a mode of the compiler which caused generated script to use the type system defined in msajax scripts.
Conceptually you should be able to load mscorlib.js and program using it in any page, including one using asp.net ajax (and update panels). As a heads-up you may run into one particular issue... mscorlib.js extends Array.prototype, which I don't think affects msajax scripts, but might affect some other scripts (eg. sharepoint scripts).
In the future, I plan to generate scripts differently that would not require extending Array.prototype, but that work hasn't been done yet.
So hopefully that clarifies things. If you try and run into issues, I'd love to know. I can't guarantee they'll be fixed (esp. given that even asp.net is primarily focused around jQuery rather then the old msajax scripts), but I can try helping to see if any of them have reasonable workarounds.
I have been asked to support a legacy app and I can't get access to the code behind files. I need to add a new feature that gets a list of items from the database on page_load, what way would adding an "in-page" page_load affect the compiled page_load?
What would be the best approach to take with this?
Since you mentioned that the legacy app has a Page_Load I assume it's .NET. This means that you should be able to decompile it using Reflector from Redgate to get the original source.
The source will likely be much less "pretty" than it was originally, but you should be able to get editable, compilable source out of it.
As for the question of an in-page page load and a compiled page load - You can try it... But I doubt it will work. You're really better off trying to get the source if you can.
I’m new to .net, though I’ve been writing in classic asp for years. I know it’s time to make the change, but I can’t stand how bloated the HTML becomes.
For example, a simple menu using a web.sitemap and adds over 100 lines of JavaScript and HTML. A simple form with server-side validation adds in masses of ugly JavaScript. And a basic table of data using GridView adds in a ViewState that makes my eyes water.
Call me a purest, though I don’t like sending data to the browser unless it’s needed. And I don’t need a form-riddled menu when a simple unordered list of links will suffice.
So, set in my ways, am I destined to forgo the benefits of the Framework entirely by insisting on writing my own, cleaner code for everything? Or am I missing the point?
As a brief aside I’m a big fan of Campaign Monitor, a newsletter distribution company. They’ve written an elegant and comprehensive user-interface in .net without a single ViewState or bizarre .net-mangeled ID reference. Even the Sign Up form on their website (/signup.aspx) is as clean as a whistle. What’s their secret?
I hope I not the only one. Any advice would be greatly appreciated.
Try ASP.NET MVC or one of the other MVC web frameworks for .NET
If your GridView doesn't need it, then turn ViewState off for it.
Also, please edit your question to say what version of .NET you're using. Some of this gets better, and some does not. You might also want to try VS2010 beta 1, and complain about anything it doesn't fix.
Another idea would be to go on treating ASP.NET like it's classic ASP. Do it exactly the way you're used to, but do it with the idea in mind that there's about 10 years of development work that's gone into solving some of the problems of classic ASP. Once you actually hit one of those problems, find out if ASP.NET has solved it, and how.
For instance, I have a hard time believing you enjoy writing FOR loops to generate table rows. If you get tired of that, learn to use a Repeater control, or a DataList control, or even the old DataGrid control. If you turn ViewState off on those, I think you may find the generated HTML to be acceptable, and you'll find it a lot easier to generate tables and other structures that repeat based on repeating data.
You can opt-out of much of that bloat by not using all the out-of-the-box controls that come with it but I prefer the MVC route that activa suggested
Here is my list:
Keep the use of asp controls to minimum
Turn off Viewstate when it's not need
If you don't want the JavaScript associated with Client Side Validation (with ASP.NET Validation) set the EnableClientScript to False
Use asp:literal instead of asp:Label
Yeah it seems to be that everyone is bashing webforms at the minute for the reasons you have outlined above. HTML heavy Controls, ViewState, no control over ClientIDs all seem to cause an issue with people.
However let is be said that you can use asp.net (webforms) and produce some decent applications.
Control of html is yours through httpModules and httpHandlers and some of the issues mentioned above are fixed in asp.net 4.0
I just listened to a great podcast comparing MVC and webforms. Its in the area you are asking about. Also check out this blogpost by a dotNetNuke regarding the good asp.net code and why people should take a breath before converting everything to mvc.
Having said that I've tried Asp.net MVC and it is awesome. I'd probably look at dotNetNukes code to as its a mature asp.net product.
Also, when you do want to use these newfangled server controls, check out the css friendly control adapters. They clean up much of the bloat.
For client IDs the key thing to remember is to let the framework handle them. If you need to get an element on the client side, remember to emit the control's ClientID property into your script.
I've been using a template system and am very happy with it. Basically write an http handler for .html files and put tokens in the html files that regex could find in one sweep and inject any stuff. (google template c# for more info).
I tried some of the supposedly cool new features of ASP.NET for a little while. I also didn't like most of them. I felt constrained to work within the limitations of the common paradigms Microsoft had dreamed, even though I new how easy it would be to produce the HTML and JavaScript myself to do specifically what I wanted to do without having to learn how to jump through the hoops of so many new Microsoft-specific idiosyncrasies.
Anyway, I stopped using the parts of ASP.NET I didn't like on new code I've been writing lately. When I first started using ASP.NET, nothing in the MSDN documentation jumped out at me about how to avoid such complications, so I posted a couple "Hello, World" at http://www.agalltyr.com/rawaspdotnet.html to help spread the heretical word. I couldn't care less if it's the latest cool technology or the recommended technique. It's a reliable and reasonably efficient tool I can use to do my work.
Oh, and I'm not in the mood to learn ASP.NET MVC either. That's just more idiosyncrasies. Give me a language (C#) and a framework (.NET), and I'll design my own abstraction, thank you.
Following my question here I run the suggested Tidy Program which came back with a whole load of errors regarding the tool not recognising ASP tags. Is it possible for a tool to validate ASP.NET pages before compile/delivery via a browser?
If you are using VS then your pages are being evaluated as you type them, mismatched tags, etc are highlighted. Beyond making sure that you have entered the HTML correctly I'm not sure what problem you are looking to solve.
My approach to any problem of this type is to solve it at source rather than patching mid-way.
you could potentially perform your own validation by overriding the appropriate render methods.
You can validate the rendered ASP.NET (and with IIS7 even static) pages using a HttpModule. For a complete example check: XHTML Validator For All.
If you log the validation errors, you can later address them directly (at the source level).