The Infragistics SharePoint Demo Is Funny, But Depressing

So, I recently got solicited for feedback and comment from Infragistics because I was for some time heavily into using their control set. Regardless of some of the unwieldy operations to sustain the nifty functions, I think they are neat and a lot of the times clients have a pre-existing license agreements so I just use ’em.

Infragistics appears to be making a tactical move into the SharePoint space; therefore curiosity arose in me to go test out what they had recently released. Regrettably, in conventional let’s hurry up and provide a SharePoint solution format which can be vendor criterion, Infragistics wins for the most cumbersome deployment process feasible. Well, maybe not that bad, but it’s pretty damn close.  The WORST part about this situation is the code behind for the solution is fantastic (not being sarcastic, it really is pretty good!), and it’s a bummer that they dropped the ball on everything BUT managed code development. Kudos to the developer on the code though.

So, here is the page of concern:
http://www.infragistics.com/hot/sharepoint.aspx#SharePoint

And here is a link to the configuration guide:
http://dl.infragistics.com/products/NetAdvantage/Silverlight/2008.1/ReferenceApplications/Pomegranate%20-%20Configuration%20Document.pdf

Alrighty, let’s get started. Once the PDF is open, scroll down to page 10.

1) Get to step one. WTF?!?! Cmon Infragistics, you want *manual* web.config modifications? LAME. That can take forever to complete on a staging farm, and is subject to substantial human error. I mean come on; the SPWebConfigModification class exists for a reason and there are all sorts of receivers.
– Moving right along, reference point 1 for the custom configuration sections instances. Are people really supposed to copy and paste that shit?
– Manual safe control entries. HA! I like that one. No note needed on that sweetness.
– Manual CAS adjustments make me want to cry. Seriously, as someone that takes code security critically, I want to shove a pen in my eye to damn the tears up like a Bic beaver.
– Again, the session state stuff? See above.
– Could go on with the rest of em, but you get the point…
2) Creating folders at the root of the site can be automated, that’s why we have SPWebApplication, etc. objects. You can even do your permission requirements as well.
3) You want people to copy things into the 12 hive. Is there a point to that? I mean, it is breaking the fundamental principle of SharePoint Solution architecture. That’s one of the reasons WE HAVE SOLUTIONS.
4) Uploading a master page can be automated since the Master Page Gallery upload is the same as any document library. Sigh.
5) As opposed to packing .webpart or .dwp files, you are asking people to new them up out of the gallery. The extent of that laziness is immeasurable in words.
6) Well, I guess back to the 12 hive thing, again, manual Theme deployment. Word.
7) After I saw SPD, I threw up a little bit in my mouth and stopped reading.

I am not bagging on the controls, but FFS, if you are going to build a sample solution, MAKE IT EASY AND QUICK TO DEPLOY. I don’t want to spend a fucking afternoon trying to get some pie charts and random data grids into a demo site.

Share

Writing Extension Methods for SharePoint

Extension methods are a formidable programming construct that augment implementation abstraction and modularize segments of code, lending itself well for filling gaps that may be present in a closed API, such as the one that SharePoint provides. Often times there may be a particular method that is desirable on a particular type, however the options for providing it are not available in the shipped API due to sealing and other modifies. Using Extension methods, it is possible to bypass this limitation while maintaining a clean implementation that can avoid deep inheritance tree references.

Extension methods are increasingly important when working with SharePoint code because a majority of objects that would normally mandate customizations of behavior, for example on SPList types, is decorated with a sealed access modified thereby negating possible inheritance. This is most noticeable when you are working with mock objects, which outside of certain frameworks (i.e. TypeMock) require an unsealed class and a default constructor.

As opposed to providing the method definition within the class, an extension method is simply defined by an association and contained in a separate static class supported by partial class constructs (i.e. it must exist in a namespace in the current scope). The method itself is invoked using instance method syntax, allowing some level familiarity in the code constructs. While the method is static, it can be called only on instances as defined in the parameters. In essence, an extension method will allow injection of a method into another class, so it is declared as if it is part of it.

In order to decrease method ambiguity due to extensions methods being defined only by the method name, it is important to take into account the appropriate naming convention (in fact, if the signature is the same the extension will be ignored!). Furthermore, the SharePoint types that will be extended are of course subject to the revisions of the API as released by MSFT. Therefore, when the API changes, there may not be the desired level of backwards compatibility.

The syntax for an extension method is very simple (it is important to note that while VB.NET requires the Extension attribute to be defined, C# does not. However in C# we are forced to create a copy of the object / return value so it evens it out!).

[csharp]
public static class Extensions
{
public static Type DoSomething(this Type type)
{
// let’s get something going!
}
}
[/csharp]

You can see that in the static Extensions class the DoSomething method has its sole parameter decorated with the this keyword modifier, to indicate the type to which this method will extend. So, for example when writing extension methods to extend the SPList class (without any supplementary parameters), our class would like this:

[csharp]
public static class Extensions
{
public static Type DoSomething(this SPList list)
{
// let’s get something going!
}
}
[/csharp]

But that isn’t doing much, so let’s take a more pragmatic example.

In the below, I am assuming that within an application, on SPList objects, I am going to be frequently reordering the current instance SPListItem collection into a descending order by the modified date, and then retrieving the last 5 items.

In the HarvestLastFive, it is noticeable that I am firstly specifying the type to target by using the this keyword with the SPList type. Following, I am building a SPListItemCollection of the SPList.Items, which then uses the LINQ OrderByDescending method in combination with the SPBuiltInFieldId.Modified property to handle the ordering. Lastly, Take returns the first 5 items out of the modified collection. If you just wanted the reordering (a variety of extensions I use daily use such LINQ collection modifiers for enhanced manipulation support) you would just take out the Take statement.
[csharp]

public static class Extensions
{
public static IEnumerable HarvestLastFive(this SPList typeToTarget)
{
try
{
SPListItemCollection collection = typeToTarget.Items;
var finalCollection = tempCollection.OrderByDescending(x => x[SPBuiltInFieldId.Modified]).Take(5);
return finalCollection;
}
catch (Exception exception)
{

}
return null;
}
}[/csharp]

You can see in the members of the Extensions class, that the HarvestLastFive method has a different icon (little down arrow) which specifies it as an extension method.

Using the method in a class is analgous to other methods available on that type. For example, the HarvestLastFive method takes on the form:
[csharp]
public static void TestingExtensionMethod()
{
SPList list = SPContext.Current.Web.Lists[“My List”];
var collection = list.HarvestLastFive();
// Do whatever you want!
}[/csharp]

Within Visual Studio, this method is noted as an extension method on the ToolTip with the prefix (extension).

This should give you enough to get going on extension methods. I will be posting some of my common extension methods that I use with SharePoint shortly, as this was meant to be an introduction.

Share

Moving Up In SharePoint Positions

I have been wanting to write this post for quite some time, mainly to harvest whether it is an industry phenomenon, and now that I finally have comments working again after the lovely group has ceased there DoS attacks on the main site, I can finally gain feedback from the greater community as to whether this is something that I have solely experienced, or if it occurs on a grander scale.

While I haven’t been in the professional development industry that long, I think that I have been in it long enough to notice one main concept.

If one desires to move up the corporate ladder, gaining higher positions, let’s say, from a *Consulting Developer* (so let’s assume the title of Consultant or Senior Consultant) to someone with their fingers in a little more higher level stuff regardless of with a company or client, so something that is basically considered a higher development position or management role (for this let’s assume the title of Principal Consultant or another management cliché here), that within said company the time frame to do so is much larger than just straight up switching companies. As I say this, do take note that I have been at a lot of companies in my past since I really only look for federal contracts that appeal to me (since I really don’t want my clearances to lapse I rarely work out of the federal industry), and this is not limited to one, but rather touches on literally all of them that I have worked at. I find it very intriguing because I would think that for company staffing resources it would be relatively consistent across the board, both are looking at your experiences, accomplishments, and aggregate knowledge, however the ratio of offers coming from external companies for the positions I am attempting to describe, well, overwhelms any type of hinting that happens from an internal company.

So, I ask you reader, is this your situation as well? I would love to hear for someone that works in the human resources division at their company.

Realistically, the only thing that I can think of is that:

1) Why move a good SharePoint developer to a new position since we can pay him the same and not risk laying responsibilities on him/her. Let’s face it. A good SharePoint developer is one that produces. So why take that away?

2) The external companies consistently have the higher level / management positions open, whereas out of all of them I have worked at, those positions don’t exist (*unlikely*).

3) I am an asshole in real life (*likely*) :-) , but I look really good on a piece of paper.

Share