I'm using an older version of ASP.NET AJAX due to runtime limitations, Placing a ASP.NET Validator inside of an update panel does not work. Is there a trick to make these work, or do I need to use the ValidatorCallOut control that comes with the AJAX toolkit?
I suspect you are running the original release (RTM) of .NET 2.0.
Until early 2007 validator controls were not compatible with UpdatePanels. This was resolved with the SP1 of the .NET Framework.
The source of the problem is that UpdatePanel can detect markup changes in your page, but it has no way to track scripts correctly. Validators rely heavily on scripts. During a partial postback, the scripts are either blown away, not updated, or not run when they are meant to.
In early betas, MS had the UpdatePanel try to guess what scripts needed to be re-rendered or run. It didn't work very well, and they had to take it out.
To get around the immediate problem, Microsoft released a patched version of the validator classes in a new DLL called Validators.DLL, and gave instructions on how to tell ASP.NET to use those classes instead of the real ones. If you Google for that DLL name, you should find more information. See also This blog post.
This was a stop-gag measure and you should not use it avoid it if possible.
The real solution to the problem came shortly after, in .NET 2.0 SP1. Microsoft introduced a new mechanism to register scripts in SP1, and changed the real validator classes to use that mechanism instead of the older one.
Let me give you some details on the changes:
Traditionally, you were supposed to register scripts via Page methods such as Page.RegisterStartupScript() and Page.RegisterClientScriptBlock(). The problem is that these methods were not designed for extensibility and UpdatePanel had no way to monitor those calls.
In SP1 there is a new property object on the page called Page.ClientScripts. This object has methods to register scripts that are equivalent (and in some ways better) to the original ones. Also, UpdatePanel can monitor these calls, so that it rerenders or calls the methods when appropriate. The older RegisterStartupScript(), etc. methods have been deprecated. They still work, but not inside an UpdatePanel.
There is no reason (other than politics, I suppose) to not update your installations to .NET 2.0 SP1. Service Packs carry important fixes.
Good luck.
#Jonathan Holland: What is wrong with using Validators.dll?
Since they replace the original classes, you are quietly bypassing any bug and security fixes, enhancements, etc. that Microsoft might release in the future (or might have already released). Unless you look carefully at the web.config, you might never notice that you are skipping patches.
Of course, you have to evaluate each situation. If you are absolutely stuck using .NET 2.0 RTM, then Validators.dll is better than nothing.
#jmein
Actually the problem is that the Validator client script's don't work when placed inside of an updatePanel (UpdatePanels refresh using .innerHTML, which adds the script nodes as text nodes, not script nodes, so the browser does not run them).
The fix was a patch released by microsoft that fixes this issue. I found it with the help of Google.
http://blogs.msdn.com/mattgi/archive/2007/01/23/asp-net-ajax-validators.aspx
If for what ever reason you are unable to use the udpated version of the ASP.NET validator controls is actually very easy to validate a validation group yourself, all you need to do is call
Page_ClientValidate("validationGroupName");
Then you can use the PageRequestManager execute the validation as you need.
Definately using the updated validation controls is the way to go, but I'm quite partial to JavaScript ;)
Related
I know that in order to use most of the controls from the Ajax Control Toolkit, you need to include the ToolkitScriptManager control on your page, and it must be the Toolkit script manager, and not the standard script manager because the extended toolkit version contains extra (java)scripts which enable the controls to work and communicate properly.
My problem is that I keep coming across projects at work from other developers where they used the standard ASP ScriptManager control, and added toolkit controls without switching over to the ToolkitScriptManager. I would have expected these projects to not debug properly, yet they are currently somehow working in test and production environments, and they do not actually break until I download them onto my freshly loaded dev environment from source control.
When someone asked me "Why do we need to replace these controls? They're working everywhere else." I could only shrug my shoulders, I have no idea why other projects are working with regular script managers.
As a side note, problems like this are what are pushing me into becoming a JQuery guy instead of a ACT guy.
Here is a question to answer since this is a Q&A site and not a discussion site: "How is it possible to run the ACT controls without an ACT script manager?" Personally, I would point to a glitch in Visual Studio of some kind, but I want to know if anyone else knows more.
ToolkitScriptManager inherits from ScriptManager and extends/improves its functionality.
You may safely substitute ToolkitScriptManager with ScriptManager just so long as you are not using any advanced feature provided by the ToolkitScriptManager.
What are those supposedly advanced feature differences you ask?
Check Here for your answer...
TMI Alert:
MS actually recommends replacing ToolkitScriptManager in certain instances if you are suffering from Out Of Memory exceptions and there are also a high number of System.Web.FileMonitorTarget objects in existence. These objects are used to check and see if the page was modified (you can see how it relates to AJAX), but these objects should go away and not be maintained.
For some reason, if you're using the ToolkitScriptManager, there are instances where FileMonitorTarget objects just don't go away and end up contributing to server memory problems, but neither I nor they fully understand why replacing the ToolkitScriptManager with ScriptManager actually helps in these scenarios, but just so long as it works, we won't continue to ask questions...
The title pretty much says it all. I have a project that for political reasons cannot be moved to a later version of .Net and would love to have a drop-in control for uploading files better than the old FileUpload control.
I'd like to use the AsyncFileUpload control, but it's not in the latest version of the toolkit that is supported in the 2.0 framework.
I've looked at some of the flash based controls, but integrating them would trigger a full regression test of the project I'm on (multiple weeks).
We've lived with the FileUpload control because our files are small, but the error handling when a file gets larger won't be unacceptable much longer.
-- EDIT --
I just found Uploadify. At first I didn't think it would work, but I checked out the forums any way. I found this link http://www.uploadify.com/forum/viewtopic.php?f=7&t=142&p=8620&hilit=asp.net#p8620 It works great. I can do whatever I want to in the upload handler.
I'm adding this as an answer for whoever follows:
I just found Uploadify. At first I didn't think it would work, but I checked out the forums any way. I found this link http://www.uploadify.com/forum/viewtopic.php?f=7&t=142&p=8620&hilit=asp.net#p8620 It works great. I can do whatever I want to in the upload handler.
I'm planning a ASP.NET project for which I'm going to use AJAX. I'm researching all the available technologies for doing so in the .NET world.
I need a solution that is well documented and stable.
The current solutions I've found are:
1. ASP.NET AJAX UpdatePanel
2. ASP.NET AJAX with Web Services + JQuery
3. JQuery + Http Handlers
In the second and third solutions the backend would only send JSON or XML messages to the client.
In my experience the best way to go is JQuery with WCF with JSON webservices.
The reason is:
ASP.NET ajax is gives you alot for free in terms of coding but is bloated from the start and needs to be stipted and slimed. On the other hand you have JQuery that you needs more development but is light weight. JQuery has a great plugin library as well.
XML is to slow, JSON is fast.
Thats how I would do it today.
All will work but I've had most performance and stability with using JQuery and a script service.
An update panel will work but as its designed to work in the general case it can be a little bloated if you aren't careful. One reason being is that it posts the viewstate back with each update.
I recommend you check out the site: encosia.com as it has a number of posts on how to use script services and page methods. Then you can make a more informed decision. I would say that I've not used page methods and probably won't but that's entirely for personal reasons.
One other thing to consider will be any mvc you may end up doing. The general consensus is that it's a whole lot easier with JQuery. Added to that Microsoft have officially adopted it and also provide intellisense in VS2008.
All compelling reasons to include at least some of it in your project. In mine I only use the built in ScriptManager when I absolutely have to.
HTH!
S
Do you guys know about an ajax toolkit (or something similar to the m$-ajaxtoolkit) for mono??
Microsoft's ASP.NET AJAX Control Toolkit works on Mono, and is open source (Ms-PL). That doesn't preclude the use of jQuery, though. There are actually several third party AJAX libraries and control toolkits that support Mono, and many are compatible or work in conjunction with ASP.NET AJAX.
I agree with Brian, but want to add that you should read Dave Ward's series on jQuery and ASP.net. He really distills the essence of what you can do with jQuery, PageMethods, and WebForms without MS Ajax. These ideas are directly applicable to the Mono / Linux environment.
Here's a list of essential posts:
Using jQuery to directly call ASP.Net Ajax PageMethods
Use FireBug To Learn jQuery
Simplify calling ASP.NET Services with jQuery
I'd recommend rolling your own using jQuery. That's what m$ is doing now anyway.
Debugging Mono website
Do you remember, that you have no development environment in this machine? You can install it, or download Mono liveCD with openSuse. But before doing it, please note, that GTK# (it’s devenv) is not very user friendly. It even worse, then Eclipse. So let’s try to understand first whether we can fix small compatibility problems without entering code.
The most convenient method to debug web site on Mono is by using XSP and XSP2 mini web servers. Just enter the directory of the site and run it. By default you’ll be able to access the site by using ... (it also be written for you). Enter and notice whether you have any errors in console. No? Keep doing
The most common problem is “error 500” with nonsense stack. If it contains ScriptManager error Type not found, the problem is in Web.config file. Try to regenerate it to be compatible to Mono (for example, Mono has different version of System.Web.Extensions assembly. In ASP.NET 3.5 it has version 3.5, Mono has only 1.0.61025.0 (the old AJAX.NET). To recreate your web.config all you have to do is to execute “mconfig af AJAX Web.config” It will create default web.config file, supports System.Web.Extensions (AJAX features).
Not helped? Keep doing. Let’s look another time into the stack – if it contains errors in “EnablePageMethods” or “ShouldGenerateScript” or “EncryptString” – the problem is serialization. Mono has very limited support for JSON, XML and SOAP serialization. Try to look into your code and notice if you have classes, marked with [Serializable] or you are transferring your own classes by using PageMethods. If so, replace it with regular strings (my grandma serialization).
Is the source code for the common login controls available?
Those are the controls which are available under Login section in Toolbox:
Login,
LoginView,
PasswordRecovery,
LoginStatus,
LoginName,
CreateUserWizard,
ChangePassword
Eventually could you point me to a good source of custom implementation of functionality that those controls provide, or some guidance on implementing this functionality without using the mentioned controls.
I am using Visual Studio 2005 (.net2)
I will be using SQLMembershipProvider as the MembershipProvider but that probably should make no difference.
"the entire framework is available" is not true. :)
The source code for the entire framework is available. The link below provides some details as to how to access:
http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx
I am going to give this a qualified "NO".
I have gone down the road of implementing an implementation of the Login server control using reflected source as a starting point (this was before symbol server integration).
Things seem to go swimmingly, with a few reflection hacks to get to core framework members that obviate reams of code.
Until you get to the designers. That infrastructure is a minefield and gets wide and deep with a quickness and is filled with even deeper buried internal types that need implementations or reflection hacks.
Ultimately wound up with a working control that I could extend but would never want to maintain.
The effort was not wasted; I learned a lot about how over engineered server controls are designed.
And then I just shifted a login control to template mode and got everything I needed to get done in a few lines of code. ;-)
Except as a learning experience I would certainly recommend against going down that road.
Good luck.