Sunday, June 22, 2008

AJAXifying the WSS 3.0 / MOSS 2007 web.config

Ok folks... i m not here to tell what AJAX is capable of doing. There are already dozens of posting that can very well tell you that.. check-out this for instance. I assume that people who are reading this are already aware.

In the same post above, you will also find mike asking you to do dozens of configuration changes in your application's configuration file (web.config)...

Yes.. thats exactly what this post is about. for my first AJAX webpart, i followed the recommended steps and got my hello world webpart working right. But the joy stayed only for few minutes when i realized that my web.config has just undergone plastic surgery.. and a major one. Are we suppose to do so much of configuration changes manually?? My experience of development tells me.."Noo"

SharePoint has given us this beautiful thing called FEATURE. No problem, well lets write one to do that.
It was not few hrs when i discovered this CodePlex feature project called AJAX.Config.

Well awesome, the overhead of writing one was off from me, not that there is some rocket science involved here more than SPWebConfigModification. I installed the feature and activated it. My web.config gets updated with required elements. I deactivated it and found my web.config rollback all the changes.

Well, that does it, and we lived happily ever after..... until something told me to activate the feature again. Ooops.. this time there's an exception.. Holy cow!!!

And after this.. the entire adding/rollingback of elements is screwed. In fact, i manually had to go and remove the config elements myself.

Doing little R&D in the code i found out that the pages section is not supposed to be added to the config cause it already exist.

So, this is how it goes. SPWebConfigModification
is suppose to do incremental upgrade on the condig if trying to add an element

so if:
<some element attribute="value"/> already exist, trying to add this element again will not result into:
<some element attribute="value"/>
<some element attribute="value"/>

Thats, the extra plumbing taken care for you in the object model apart from updating
the farm.
But wait a minute.. what happens when you deactivate the feature. The same method takes a bool parameter to undo the modification.. or better speaking, remove the SPWebConfigModifications from the collection and again update the farm. This is what happens after you deactivate:

Now again try to activate it. It doesn't have any pages section any more. But it is not the pages section which cause the exception, its the controls element that cant find any page section to embed itself in

This is what, atleast, I have discovered till now in the project. Feel free to report if you have anything to add. The updated code can be found on my esnips public folder

Feel free to comment.

1 comment:

electronic signature software said...

Thanks for your post, it wll definitely help me start contributing with the projects I use and was trying to figure it out how to help them.