Ajax enabled Web parts

                I have run into numerous questions and comments on AJAX enabled web parts and seen way to many partial answers that get folks with sight of a functional web part only to dash their hopes. So I am going to throw my hat in the ring and post some code here from one of my AJAX enabled web parts which has been in production for 7 months now. Like everything else, there are different ways to do it so don’t think mine if the only way. It is just one of the ways that works.  I took some liberties here in assuming your current level of expertise in coding web parts and AJAX.  If further explanation is needed, please feel free to post some comments and I can adjust this post.

                First, you can only have 1 Script manager object per page. A good way to do this, embed it in your master page.  Sooner or later someone is going to create another AJAX web part and if you allow folks to push script managers into web parts you will end up with a new web part that breaks yours and theirs.  It is easier to just put it in once in the master page and tell your web part developers to refrain from doing so in their code.

                Next, use the oninit function as the point to set the async triggers and call the EnsureUpdatePanelFixups function I will include further down.

Creating Update Panel object

                I created a helper class to set the values on the update panel and other controls. Here is what I did for creating my Update Panel.  This function is called in the onInit class.

                public static System.Web.UI.UpdatePanel CreateUpdatePanel(string id)

            {

                System.Web.UI.UpdatePanel updatepanel = new System.Web.UI.UpdatePanel();

                updatepanel.ID = id;

                updatepanel.ChildrenAsTriggers = true;

                updatepanel.UpdateMode = UpdatePanelUpdateMode.Conditional;

                return updatepanel;

            }

                This function is called in the onInit as well. It will override the usual javascript submit functions in MOSS.

private void EnsureUpdatePanelFixups()

        {

            if (this.Page.Form != null)

            {

                string formOnSubmitAtt = this.Page.Form.Attributes["onsubmit"];

                if (formOnSubmitAtt == "return _spFormOnSubmitWrapper();")

                {

                    this.Page.Form.Attributes["onsubmit"] = "_spFormOnSubmitWrapper();";

                }

            }

            ScriptManager.RegisterStartupScript(this, typeof(ProcessSearch), "UpdatePanelFixup", "_spOriginalFormAction = document.forms[0].action; _spSuppressFormOnSubmitWrapper=true;", true);

        }

Finally once both the previous code blocks have been called:

//Search submit button async postbaclk trigger

 AsyncPostBackTrigger UpdatePanel1SearchPostBackTrigger = new AsyncPostBackTrigger();

 UpdatePanel1SearchPostBackTrigger.ControlID = BTNSUBMITSEARCH;

 UpdatePanel1SearchPostBackTrigger.EventName = "Click";

 AsyncPostBackTrigger UpdatePanel1WorkflowSelectPostBackTrigger = new AsyncPostBackTrigger();

 UpdatePanel1WorkflowSelectPostBackTrigger.ControlID = DGWORKFLOWLIST;

 UpdatePanel1WorkflowSelectPostBackTrigger.EventName = "ItemCommand";

 UpdatePanel1.Triggers.Add(UpdatePanel1SearchPostBackTrigger);

 UpdatePanel1.Triggers.Add(UpdatePanel1WorkflowSelectPostBackTrigger);

This last section will create async post backs triggers for the specified control events within the panel. Keep in mind, I specifically set the ID for the control and the event that will kick off the async postback. In this example it uses the Click event of a button in the update panel and the ItemCommand event from a datagrid that is inserted in the panel. The controls referenced here MUST be in the update panel

                I imagine this will be a multiple part posting as off the top of my head, I think I could write an 1,110 page book on this topic. I got a new one the other day which I had never tried, but really, when it was shown to me, it scared the crap out of me.  One of the biggest things to take from these posts, have a solid and TESTED Backup/Recovery process in your organization. Do NOT just give it lip service, write it on paper, file it away (ironically probably in MOSS), and wait till your first major failure to fully test it.

                I will give you a real life configuration I have worked with which would be majorly impacted. Adjust to your own real world scenario. So, let’s assume you have a 5 server production MOSS farm, 2 A/P clustered SQLs, 1 index, 2 WFEs. You have 3 web apps in your portal. You have a custom membership and role provider.  You have 4 or 5 custom web parts. Maybe a server control or 2 you have thrown in that uses an entry or 2 in your web.config app settings. For fun, let’s throw in a customized CAS file. You also have some SSL settings you had to configure in IIS as well as some Metabase configuration you had to screw with since you are using host headers across SSL. Maybe your did some IPBinding, who knows .

                WFE1 is being a PITA. You get royally annoyed by the WSS Services misbehaving, or you are getting a freaky error on that box, or you are bored and a masochist so you are playing with your production configuration. For whatever reason, you decide to stop and start the WSS services on that WFE. You click stop. Give it a second, click start. Your memory issue or whatever issue prompted you to restart that service disappears. You are happy, for the moment.  Then your custom web parts start kicking off errors. Probably security errors.  As a matter of fact, you are getting sporadic errors where users cannot even log into your web applications through FBA anymore.  Most likely, you get issues where the server cannot resolve the url to the web apps anymore.  All hell is breaking loose. So what happened?

                To see what this actually did, grab a virtual with MOSS on and at least 1 MOSS web app. Open ISS, open a windows explorer session to the inetpub folder for your web apps. Now that you’ve got your window open,  go into Central Administration and stop the WSS services. You will see your IIS web apps totally disappear along with the inetpub folder for your web apps in windows explorer. Start the WSS Services. They reappear.  Man, how did MOSS do that?  Geez, it is smart you say. Not really, it pulled the information it needed out of the MOSS farm configuration DB.  When you reactivated WSS Services, it rebuilt the web applications and your inetpub folder(s).

                Back to your production scenario. You had those SSL settings, the metabase settings for your host header/SSL setup, your web config and Code Access security mods. Then you start to panic as you realize, MOSS rebuilt those web apps using the MOSS configuration DB. Your mods to IIS, web.config, CAS, etc, MOSS knows absolutely nothing about those. You make those settings totally outside of MOSS. In essence you just blew them away. What you have created is an opportunity to discover just how good your backup/recovery process is for the file system of your WFEs.

                If you restart your WSS services through the central administration site, keep in mind, MOSS will rebuild the web applications on your WFE from the MOSS configuration DB. Any modifications you made outside the realm of MOSS, will be gone.  If you have not taken steps to back up your metabase and your file system mods you will now get to do them again, manually.

                So, a couple lessons here. First, backing up MOSS involves more than just your DBs. If your DBs are all you are backing up. You are probably missing something. Second, even seemingly miniscule tasks like turning on and off WSS Services can have MAJOR impacts to your farm. Giving an untrained individual access to central admin and throwing a shiny new “Sharepoint Administrator” title on him/her, is akin to handing them a case of nitro glycerin, labeling them a demolitions expert.  Train your staff for the role and once trained they will give you point number 3….ALWAYS test even simple actions like this on a disposable test system BEFORE production. Not just a VPC sandbox, but a fully fledged test system that mimics production. A single server sandbox and a multi-server farm behave differently in many areas. If you have a multi-server production farm and you do all your testing/validation on a single server sandbox, you will have issues. Sooner or later you will create issues on your production environment, and they will be real fun to debug.  You can virtualize the entire test system, but create one and use it.

                How many times have you gone through MOSS and looked at labels, descriptions, grid headers, etc, on the standard MOSS UI and thought, “Man…what I would not give to be able to change that wording!”? 

After attending an architecture class in Atlanta with Bill English, my mischievous streak got the better of me, and I set out to figure that out myself.  I started with the “Application Management” page in central administration, otherwise known as applications.aspx.  I had assumed that the text was maybe somewhere in the DB. Given the Central admin content DB is actually not that large, I dove in and set out to find the point where this text constant was defined. To my dismay, I only found the text from the navigation/menu bar. This text can be changed through the MOSS site settings UI in central admin, I would not recommend running UPDATE queries directly to the MOSS DB. While I am on that topic, keep in mind this expedition was conducted on a virtual, please do not crack open the DB for fun on a production server.  This may seem like extreme common sense however, we all know common sense is not always that common.  If you crack open the MOSS DB on your production server and screw it up by making what you think is a minor change, well do not expect MS to be too helpful when you call support.

Back to the hunt, After failing in the DB it occurred to me, that maybe just maybe there was a config/resource file guiding these constants. After all, MOSS is available in a ton of languages, and I could not imagine MS embedded all these text constants into the binaries for MOSS. To my surprise, indeed, MS has embedded a TON of those string literals your find throughout MOSS in a series of resource files which are located in the inetpub\wwwroot\wss\virtualDirectories\<web app dir>\App_GlobalResources folder. The one I was looking for, “Application Management”,was in the SPAdmin.en-US.resx file. So I spent a few minutes having some fun, modified the “Application Management” to “Application Manglement”. Changed a mess of the page descriptions, link text, even removed the “Zones” text and renamed it to “Incoming Vectors”, a term an instructor mentioned in a class which better describes the use of those values.

So, in practicality, is there any use to this beyond having some fun and getting a little more insight into lower level design in MOSS? Well, I could certainly see some of my clients, particularly those who were more hung up on some of the wording in MOSS taking a good look into this. There are a LOT of resx files, A lot of values to modify. Is this something you would want to do? Maybe, but keep in mind if you did decide to take this and put it to use in a productive way:

1.        Back up your original resx files.

2.       You will need to modify these on each WFE.

3.       You will need to add these modified files to your backup/restore planning.

 One more “little” thing. I would not in the slightest expect MS to be in a position to have tested what would happen to their application when folks modified the resx files. I have not tested this full fledged in a large farm, and I cannot guarantee that there is not some embedded code in the bowels of MOSS, that would go beserk when you modify these values. I would expect that you would be fine, after all this is what resx file usage is for, and embedding resx values (vs keys) into your app sort of defeats the purpose of having one. However, MS still hires humans to do their development, so I cannot guarantee that they always follow best practices. That being said, it is awfully fun to mess with