Moved the Custom Field Controls Project

Hey guys.. i am gradually moving all my projects to CodePlex.

You can check the Custom Field Controls project(renamed and enhanced the project)

Removing *.webpart from the Web Part Gallery in FeatureDeactivating Event

Removing the web part from the Web Part Gallery when the feature is deactivating is the most obvious thing that anyone would wanna do. Now please dont tell me you'd tell your client to go to the Gallery and knock it off himself.

The obvious solution that we are looking at is doing something in FeatureDeactivating. Might be accessing the Web Part Gallery like a List and knocking off the Item based on some query.

So let say we have a webpart (i would reference the Recent Documents Web Part as i speak). We want to query the Web Part Gallery and knock this guy off.

Initially i did a stupid query like this:
. I Know you must be feeling sorry for me.. even i am. This is not the solution..or is it?? We can very well have webparts in the Gallery with same Title.. who'll stop your client from doing it.



The only fool proof method here i can see, or apparently see, is reading the *.webpart or *.dwp and checking for 5 part type signature



Well, lets do it then, read the SPFile of the current ListItem and knock the guy off! This is the *.webpart we are talking about

.

Well, lets go ahead and read the type element and knock it off.



(I forgot the counter++ in above snippet..well, wrote it only for illustration you see)

I happily installed the feature and tried playing around with Site Collection Feature
I activated the Feature and webpart got loaded (if you dont know.. you dont need to do anything to load the *.webpart in the Gallery... Feature Activation does it automatically for you for reasons i dont know.. i guess its made that way in WSS 3.0.. well i am not the conceptual god in sharepoint.. ask that to Andrew.

I now deactivated this feature and then went to the gallery....What the heck!!!.. this guy is still here

On debugging i found this out:



Tried out few stupid things just to content meself that i m trying to crack something here. Wait a minute!!... Holy Cow!!.. i know why is this happening.. i exactly know why is this happening!!.



My God!!.. dont tell me know i have to get all the uid's and schema's to initiate a XmlNameSpaceManager before I feed it to my XPathDocument

No i wont do it.. I rather would prefer to write a recursive code block for this:



Then use it in the code like this:



You can also go a little ahead and not hard code the attribute value like this:

Sharepoint.Webparts.RecentItems.DocumentsAggregator,
CoolStuffs.Webparts.RecentItems, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=66a50cd71f898803

If your FeatureReceiver is in the same project as your webpart, which i think it would, in almost all cases, then you can use reflection to do that.



The Code sample doing this can be found in my Recent Documents Project's FeatureReceiver

Recent N Documents Webpart for Sharepoint

Before I proceed, a great thanks to Jan Tielens and Robin
who tolerated me even in middle of night!!

Coming to the webpart...little upgrade that this guy has over Jan's SmartTools - WhatsNewWebpart v1.1 is that it gives configurable "Group By" property and ability to sort on columns(asc/desc)

So you must be thinking whats the deal about this thing.. its just another webpart that uses SPSiteDataQuery to get some recent data from document libraries like the Content Query Webpart. Well, yes it probably is and there is no rocket science involved here.

Only one problem here that i faced was "sorting and grouping together!!"..
Initially we get a cool "group by" in SPGridView but when you click on the grid's column for sorting is when things get a little awkward like this:



This started worrying me so much so that i almost forgot the most basic SQL thing there is:

always GROUP BY somecolumn ORDER BY somecolumn

Envisioning the above scenario, my GROUP BY and sorting (ORDER BY) were two different things that were not related and hence once i try to sort on any column, it damaged my group by
First i thought of doing the sorting in the CAML that is fed to the SPSiteDataQuery itself. But it started getting a little tedious thing as my SPGridView and the DataTable getting bound to the grid was getting generated in the CreateChildControl() event and the Sorting is a postback event of the control that happens after the CreateChildControl.

The logical solution i could see here was performing the group by and then sort by in the DataTable object itself and then binding the updated DataTable a little late in the control life cycle to the Grid..in OnPreRender for instance.

This obviously meant that i write some extra bit of code but it was not late that i discovered that Microsoft has already done that for us in DataSet Select DISTINCT Helper Class and CREATE TABLE Helper Class.

The Webpart can be found on my CodePlex Page

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.

Five Things the IT Manager Should Know About Microsoft's LINQ

Hey, this is an excellent case study by John Paul Mueller

You may not have heard about Microsoft's new brainchild, Language Integrated Query (LINQ). If you did hear about it, you may have yawned and put it down as yet another new technology searching for a requirement.
However, LINQ is different from most new technologies because it really can do everything it says it can. After working with LINQ for nearly a year, I've found that LINQ hasn't disappointed me, as have so many other technologies I've tried. LINQ is incredibly easy to use and quite reliable. The fact that I'm not alone in that sentiment is attested to by the large number of third-party add-ons created by other developers who feel the way I do about LINQ.
If you haven't encountered LINQ before, here's the straight-up definition. LINQ is a kind of query language, sort of the same as SQL, but the syntax is a little different. The basic idea is that you ask a question (or rather, your application does) and LINQ provides the answer from the data source you specify. That data source may not be a straight-up database. For example, if you ask LINQ which employees are in the accounting department and you supply Active Directory as the data source, the LINQ gets the answer for you from Active Directory.
Plenty has been written to explain LINQ to software developers. Here, I explain the important points for IT managers to understand.


1. Developers Can Access New Technologies Without Knowing Much About Them


A primary LINQ benefit is in reusability. A complex query you create to access objects also works with Active Directory, Microsoft SQL Server, MySQL, or a Web service; developers don't have to keep learning new techniques to use LINQ.
The basic LINQ setup comes with access for all of the data sources you might expect: data objects, SQL Server databases, XML and DataSets. However, if you stop there, you're missing LINQ's big picture. You can access a wealth of other data sources by obtaining a third-party provider—that is, LINQ add-ons, written by someone who isn't affiliated with Microsoft (and there are a ton of them). You can find common data sources, such as Active Directory, and uncommon data sources, such as Resource Description Framework (RDF).

To access data sources other than those the programming environment natively supports with most technologies, you have to jump through hoops or work through odd programming scenarios. If you make a change, a whole bunch of code usually has to change. With LINQ, you use the same query all the time. That simplifies the development process considerably, particularly for a programmer who's new to a project and hasn't made friends with the team's DBAs yet. Need a slightly techie example? Let's say, for the sake of simplicity, that you start with a C# string array like this:




To find all the strings that are more than three characters in length, you use a query like this:



In this case, ThisQuery is the output from the query process. You don't define an actual type because LINQ takes care of that for you; instead, you use var as the data type. The code uses StringValue to hold the individual data values from QueryString that match the where condition StringValue.Length > 3. The select portion of the query merely tells what to choose from the data source. Now, here's the really neat part. You can use that same query to retrieve data from an RDF or from Active Directory. If you have a provider for the data source, you can get to the data, using the same code. How cool is that?
Don't think that LINQ is limited to safe open-source projects or to Microsoft-specific data sources, either. LINQ works just fine with MySQL, as well as with a whole world of additional LINQ data sources.
You might assume that LINQ queries can't handle complex situations. The example in this section gives you a good idea where someone discovering LINQ will begin. However, LINQ queries, just like SQL queries, can become somewhat complex as you add data sources and output requirements. The learning curve to those complex queries is a gentle one, but even so, LINQ can become complex (like any other technology) as you ask it to do more work.



2. Developers Can Create Complete Applications With Less Code

Initially, I was leery of Microsoft's claim that LINQ would produce applications using fewer lines of code. I have seen way too many solutions that failed to fulfill that promise. I didn't change my mind until I started creating SQL Server queries with LINQ. But lo and behold, it took a single line of code for the query with LINQ, when previous programming used to require eight lines to accomplish the same thing.
You do have to add two more lines of code to create a data source object to use in the LINQ query, but you have to do that when working with .Net applications anyway, so you aren't losing anything.
You may be thinking that you don't get something for nothing. You're right. LINQ requires that the developer supply a provider, just as when accessing a database in Visual Studio. The provider acts as an intermediary between the data source and LINQ. Consequently, LINQ reuses code to achieve a result. The point is: Unless you need to access a custom data source, the developers don't write the provider code. That means that your development staff writes less code overall because the provider contains much of the code you used to write by hand. Fewer lines of code mean fewer opportunities for errors to creep in. And that's less work for your QA department.


3. Developers Can Develop Applications in Less Time and With Fewer Errors

LINQ makes code easier to understand. (At least, it's easier for programmers to understand. Nontechnical managers may not find it quite as transparent!) It relies on a SQL-like syntax that many developers already understand quite well. As with SQL, you specify only what you want as output—LINQ takes care of determining how to get that output for you based on the provider you specify. When you combine writing less code with a simpler coding environment, you get an application that requires less time to create.
The LINQ applications you create also should contain fewer errors. The developer who created the data source provider has already debugged and optimized it for use with LINQ. Because the developers write fewer lines of code and because each line of that code relies on basically the same structure, it's easy to produce applications with fewer errors at the outset.
The LINQ debugging functionality from Microsoft also makes the debugging process exceptionally easy. You can watch each query grab every bit of information in the result if you like. Microsoft really did do something right this time.
That doesn't mean everything is always perfect. One potential time sink with third-party providers is that some don't embrace all of the LINQ features. If there is a potential for errors today, it's because the third-party provider you use isn't quite complete.
LINQ has a number of methods to help a developer create a complex query. If a third-party provider doesn't support all these methods, the developer has to find ways around the omissions. Microsoft needs to create a program for authenticating these third-party providers, ensuring that the provider is complete, and giving the vendor a seal or other recognition when it passes. Even so, the worst third-party provider that I've used has enough functionality to create any query that most developers need.


4. Combine Data Sources without Resorting to Odd Programming Tricks

Developers will love LINQ's ability to combine data from multiple data sources in the same query. So will the managers who wish that developers could finish projects faster, particularly when those projects interact with other Microsoft products and services.
For example, say you want to locate all the employees who work in a particular building on the office campus, and then look for those employees in a payroll database. Using LINQ, you can create a single query that takes the output from Active Directory and applies it to a SQL Server database query. Likewise, it's possible to combine a SQL Server query with a MySQL query or to add a Web service query to a product search in RDF. The possibilities are endless.



5. Get New Developers Working Faster

One problem for new developers is that technology has evolved in a big way over the years. When I started writing code, all I needed to do something interesting was write a few easily understood BASIC statements. Five or six lines of code could at least display a set of lines on the screen. Today, a new developer has to jump through all kinds of terrifying hoops to build even a simple application. If the new developer doesn't know the innermost secrets of objects, forget it; trying to create any kind of application is a lost cause. Even if the developer has plenty of experience, bringing a new person on board requires a fair amount of time invested in learning every nuance of her new environment. LINQ won't solve every problem in that steep ramp-time, but it certainly can help.
LINQ helps you take a step back and get the new developer working faster. A new developer who can do something interesting and useful within a day or two of reporting for work is significantly happier and more productive. Productive developers spell great applications in less time. There isn't any secret here. LINQ simply removes some of the complexity of programming by relying on a provider to do all the heavy lifting. All the developer needs to know is what should appear as output, not how to get it.