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.
Related
My team is currently working on a substantial update to an existing ASP.NET 3.5 application which uses the Ajax Control Toolkit on virtually every page. We've found that in many cases that its use is unwarranted (clearly a previous developer decided to "Ajaxafy" everything), and a richer - and simpler - experience can be found using jQuery.
We've also found that the AjaxControlToolkit can be a pain to work with frankly in terms of maintainability and performance when you have half a dozen developers working it. We're debating scrapping its use completely, and going with jQuery for the UI experience. We're fortunate to have enough time to do this safely, and every feature we use can be replicated without any problems (AutoComplete, Calendar Control, etc).
It seems Microsoft are siding with jQuery with its addition to Visual Studio lately, and the current Ajax Control Toolkit isn't in ASP MVC (client side files only). Therefore I'm personally siding with jQuery for the moment, as it seems to have a future, while the Control Toolkit's future is a little more cloudy.
However, from a maintainability perspective, how is jQuery to work with?
It's essentially just Javascript, so no plugins required. Are updates stable, and do they often break existing functionality?
We use jquery extensively with asp.net 3.5 and have upgrade jquery and jquery ui about 3 times without a hitch. Both times we have had noticeable speed increases. Maintenance has never been an issue in about 2 years of use with 5 developers.
We find jQuery very readable and enjoyable to code with.
Don't give up on AJAX just yet. Both AJAX and jQuery are useful as long as you're using them to do what they're suited to. I really don't see too much of a difference in maintainability, it's all still code. You need to test new releases/updates before putting them into production; vet any 3rd party code you're integrating into your code base, and make sure that you're not using AJAX/jQuery to pound a square peg into a round hole.
As to the pros/cons of AJAX vs jQuery:
AJAX beats out jQuery when it comes to:
Server-Side integration
CLR Features and Feel
JSON and WCF
jQuery beats out AJAX when it comes to:
Animations
Being Lightweight
DOM Selection
Attribute / CSS Manipulation
The ACT isn't in MVC because the control structure is deeply embedded in the web forms product; most vendors (like Telerik, Component Art etc) are actually writing a separate code-base for MVC because of the complexity of making it work with two frameworks, although Telerik did a good job of it (you can use the web form controls in MVC, though the MVC-specific controls are much nicer to use).
I like JQuery, and for a project, I believe we are going to go Telerik/JQuery and plugins, so that is always a good bet.
Also, the ACT does have a lot of scripts and may not be applicable in all scenarios, but the real issue is adding too much AJAX when it isn't warranted, something that can be a problem with any other framework too.
HTH.
jQuery is tested pretty extensively. I don't remember a break caused by an update, you mileage may vary. They would likely know about any compat problems and warn about them in the release notes or elsewhere.
Recently I was asked the following questions in an interview:
How will you do performance optimization over your jQuery in ASP.NET?
How many script managers can you have in an ASP.NET application? Why? (AJAX related)
Could someone explain the answer to these questions? I have no idea about either of them.
You can only have one ScriptManager on a page. The script manager has several responsibilities, such as loading the MS Ajax libraries, creating proxy classes for web services, and enabling partial page rendering (e.g. UpdatePanel) support. It doesn't make sense to have more than one per page, and you'll get an exception if you try to do this.
If you need to load additional scripts or references, in a user control for example, you can use the ScriptManagerProxy class.
Regarding (1)
Use tools like firebug or dynatrace to do the profiling and digging the code.
JQuery is not out of nowere its JavaScript so one has to know it well for optimization.
Adhere to good JavaScript coding practices that helps big time.
Always remember that each JS file and line of code you write is transfered to client for execution so be aware of it while writing code as this cas cause issues. So if you decide to include 4 JS file sum sized to 400 KB emans u are putting burdon on the client especially if he is on slow lines.
Yes and for (2) refer http://forums.asp.net/t/1073734.aspx link.
One page can only have one script manager.
Hope that helped :)
Watch your selectors, especially when you are working with .NET. You don't want to run the same selector multiple times. Instead you would want to define a javascript variable to hold the selector and then use that variable...that way jQuery is not having to find the same selector multiple times.
You can have 1 ScriptManager per page.
You can have only one ScriptManager per page
A page can contain only one script manager in its hierarchy according to the documentation. For jQuery optimization, it is important to use minified versions of all JS files and profiling tools such as Firebug are helpful.
This would be an normal statement for performance optimization,
Performance is an important aspect of the modern day web application development. Not only does it make a site seamless to use, but also increases the scalability of the website and makes it future proof. In this article, we will look at various aspects of improving the performance of ASP.NET web applications. We will only concentrate on the browser/web server side performance as opposed to server/app server/database server performance optimizations.
You can have only one scriptmanager per page otherwise you will get an exception when you run the application.
you can also refer this link for Interview questions and answers.
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.
I didn't see an option to create a web site in the c++ area. Is there a way around this or am I just stuck with C# and VB.NET
A bit of googling turned this up, not sure how applicable it still is:
http://www.codeproject.com/KB/mcpp/helloworldmc.aspx
However, I'd question WHY you'd want to use C++.NET over C#, given that the languages are fairly similar at the basic level. Any perceived "speedups" would probably not be very noticable given that they both compile to the same IL, and as such are both subject to the JIT-compiler.
You can probably make your website work using C++/CLI. There is no tight coupling between a .NET page (aspx or ascx) and the language of implementation. You might even get the intellisense from within the aspx/ascx files but don't quote me on that.
So to set this up you would need to create a C++/CLI project and use managed C++ to extend Page, Control, etc classes, use HttpContext etc.
Another question is whether or not there is any point doing that. You would still be targeting .NET and calling to the same API. There won't be much performance benefit if at all and you will lose the IDE support for creating controls and you wouldn't be able to use WebForms from the designer.
Edit. If you haven't done ASP.NET before you will almost definitely be firing up a normal ASP.NET project and seeing how to implement something, which classes to extend etc. So it kind of defeats the idea of using another language.
You can, in theory, use any .NET language to build ASP.NET pages. F#, for example, is fully supported in VS 2010. Whether all languages are fully supported in the tools is another question -- particularly for a language like J# that has been deprecated beyond VS 2005 and doesn't support the full depth of features of the other languages (such as the ability to create new attributes).
At a minimum, you will need to do things like define an appropriate build provider to get things going.
I'm struggling with a few in-house developers that are creating some web apps in VS 2008 using C#.
It appears that the native tools and components in VS 2008 are not being nice about creating Web Standard code.
For example, the navigation component creates items in its own table structure.
Is there anyway to make a web project from Visual Studio create nice, clean, browser friendly code?
You can use CSS Friendly Control Adapters to alter the output of the current ASP.NET controls. It's easy to set up and you don't have to change any existing source code.
If you're bound to ASP.NET WinForms, you could create you own set of controls or use 3rd party controls. There is also a XHTML configuration setting you could set to Strict, so that the controls try to render more valid core.
When you really want to write nice, clean, browser friendly code, you could take a look at ASP.NET MVC. ASP.NET MVC gives you complete control of the output, but that means you have to do all the things WinForms currently does for you, yourself...
Certainly. If a component doesn't produce markup you like, then you don't use it. It's just that simple.
Having said that, be sure to check out Visual Studio 2010 beta 1 to see if your issues have been addressed. If they haven't, then you get to complain about them in a way that might get them fixed.
VS 2008 web projects don't do anything web-standards-unfriendly. The standard ASP.NET controls (like the menu control you mentioned)? That's another story -- some use a mess of tables and javascript to do their thing.
The good news? You can use what you want of ASP.NET without having to use those controls if you don't want to.
Go MVC !!! you will have complete controle over your UI
My two cents: machine-generated code is almost never as standards-compliant as the code I write by hand, especially when you get into fancy widgets and whatnot. The obvious trade off is that writing code by hand can be tedious and time-consuming.
We've come a long ways since the dark ages of code-junk that frontpage or dreamweaver used to spit out, but even still...
In the end, your code is only ever as good as your programmers.
The Web Projects themselves are simply containers for the code that you create and a mechanism for managing and building the compiled project.
Based on my experience, the controls generated by VS comply to web standards ... that being said, browsers differ on which standards they do or do not enforce and how they enforce them. For the most part, you have a high level of control of the HTML that is output from your page. The table structure generted by the navigation control id valid HTML - you may be wanting to avoid the use of tables in which case, that particular control might not be for you.
For the most part, when you have a complex control you will need to take what you get - the HTML that is generated may not be intuitive to you and your team but that is often the price paid for the time savings gained by using a pre-built control, particularly one that is intended to service the needs of a wide variety of uses. (The same can be said for most code/script libraries you use/buy/find)
Many controls offer templating that provides you with the ability to define a template for how the resultant HTML is generated.
If you want cleaner markup, you have a few options:
a) Check out the CSS Friendly control adapters from codeplex. They help alot with certain controls.
b) Avoid the more complex server controls. There is very little one can't do nearly as effectively with a repeater and some user controls that one can't do with most any databound control for instance.
c) Try ASP.NET MVC. No neato server controls to do UI lifting, but it will let you make very, very clean UIs.