OTB SharePoint forms and jQuery

SharePoint Forms and jQuery

Sunday, 1 September 2013

3:06 PM

For OTB forms SharePoint uses the hierarchy of UI controls to create the "id" and "name" attributes for their fields. This is a functionality that SharePoint inherits from ASP .NET

Sometimes you may want to get a 'hook' on one or several of these fields, without modifying the OTB form, to apply styles or modify the control behaviours  (i.e. make them read only). 

Since the developer doesn't have any control on the name and id attributes generated by SharePoint another attribute must be used to effectively get a reference to any of the fields.

First let see an illustration of the html mark-up generated by SharePoint and then we will see another attribute that can be used to get a reference to a field or fields in a SharePoint OTB Form.

If You go to an OTB document library such as the Document library and click on "new document". You will get a form, for adding a new document, consisting of a single input field with a browse button.
 

Using your favourite browse you can inspect the name and id that SharePoint (ASP .NET really) render/creates on the client side. 

In this case we can observe that the name of the field is made of the Main Content control ID plus the name of the section where the field lies, which in this case happen to be a table row ( Html element),  plus the Input field own id. The main content control is the asp:content control that you see on the form should you open it with SharePoint designer:  <asp:Content ContentPlaceHolderId="PlaceHolderMain" runat="server">
 

There is another property that gets generated and it "title" As you can see from the screen shot below the title attribute of this field is "Choose a File"

Using the title attribute we can get a hook or reference to this field and perform operations on it like we would on any HTML Element using jQuery:

 //we hide the field by using the whole title property

("[Title='Choose a file']").hide();

//we hide any field starting with the term 'Choose'

["[Title^='Choose']").hide()

 //we hide any field ending with the term 'file'

["[Title$='file']").hide()

The cool thing about jQuery wildcard selectors is that if you have several fields that have a title attribute starting or ending with a common term such as 'employee' and you want to apply the same operation to all of them then you can do with a single line of code.

["[Title^='employee']").attr('disabled','disabled')

This would make any field with a title starting with 'employee' a read-only field.

Designing to a common interface - Application loggers for SharePoint and ASP .NET

Last week I decided to start working on an application that I am planning to release as an open source initiative. My contribution will not be a framework but rather an application that will help schools to manage their information in a better way.

As I am slowly starting to work on the design of the application I started by tackling one of the Cross-cutting concern: Logging.

It is a good practice to centralized your logging code so if there are changes on the requirements, for the logging of your application, it will be easier to perform these changes.

Consider the case where an application was originally developed with logging to files, on the file system. If there is a change on the logging requirement, say the application needs to write its logs to a Oracle or MSSQL database tables, how easy is to change the code of the application to accommodate this new requirement?

If the logging functionality is scatter all over the different layer of the application then the changes will required a greater effort. On the other hand if the logging functionalities are centralized then the changes are isolated requiring less effort.

When building modules and applications it pays off to develop them having in mind 'Anticipation of Change'.

So I want to have my logging functionality centralized as much as possible and would love to have a common or related logging API for ASP .NET and SharePoint.

After some thinking I came up with the following design

 The logger to be used for SharePoint and ASP .NET implement a common interface. The interface ILogger and the classes that implement this interface , the SharePointLogger and WebLogger, can be built into the same assembly providing a common library that can be shipped for both platforms.

The SharePoint logger inherits from the SharePoint class SPDiagnostServcieBase. Inheriting from the SPDiagnosticsServiceBase allows us to have our own custom diagnostic categories and use the WriteTrace and WriteEvent methods to perform logging. You can read it up more about the SPDiagnosticServiceBase class here

The WebLogger on the other hand contain a logger property that can be an a type of a .NET logger library or framework such as Log4Net.

How the SharePointLogger and WebLogger implements the logging of errors and messages is abstracted from their clients, the classes our component using the logging API. 
In fact we could change the .NET library used by the WebLogger and that shouldn't affect other layers of the application such as the Database layer as long as the interface contract remain the same. The interface contract in this case being the methods Log(String category, String message) and LogError(String category, String message).

This design achieves the objective of centralizing the logging functionality for the application. It also makes it possible to ship the loggers to both platforms ASP .NET and SharePoint.
As an added bonus, we all like bonuses,  this design abstracts the logging logic away from other classes/components.

Many of the concepts that help us to write  re-usable code have its root on sound Software Engineering principles and programming paradigm such as OOP (Object Oriented Programming) help us to implement these principles.

On this note, I would like to recommend you  Fundamentals of Software Engineering (2nd Edition) by Carlo Ghezzi, Mehdi Jazayeri,Dino Mandrioli

This book is timeless and highlight the good principles of developing re-usable and robust software. A good companion book for any serious developer that views writing code as a Craft.

This link to a PDF lecture will give you a highlight of the third chapter of this book where it briefly mention the Software Engineering principles. Other chapters, of the book, dive-in deep into these principles and how to apply them.

We can be agile and write good code. ;-)

Design for thought

Before I start developing a new piece of software, be it a new module for an existent software or a new application I find it useful to create couple of UML diagram to get a feeling of the design and the different moving parts that will make up the new module or application.

On the spirit of being agile and yet no cowboyish I just create the necessary information on the diagrams before I star development. There is a good post on whether UML is dead or not. I concur on how the author uses UML on his projects. Is UML on the way out?

You could have few UML diagrams and yet apply your favourite agile approach such as TDD (Test Driven Development) to the development phase.

Now a bit of context. I want to build a web application using the suepr-dupa .NET technology. This web application will help school to manage their information. The application is targeted to schools in developing countries so for simplicity the components will be deployed on a single server.

Few infrastructure requirements that can start our brain working are:

• The application will run on a .NET web server.
• The application will follow the three tier model.
• To minimize up front investment on new hardware the application components will be
  deployed  on a single server.
• The application will use a relational database for the storage of its data.

The .NET web server is easy to pin point. IIS.  IIS comes already as a role in many windows server operating systems such as Windows 2008 and 2012. The database can be MS-SQL 2008.

So a simple deployment diagram , based on are few infrastructure, look like this:

As we can see from the above diagram the application will be available to users via personal computer or laptops or/and other personal devices such as tablets and smart phones. HTTP will be the application protocol Notice that I only put the necessary information on the deployment diagram.

This deployment diagram got me thinking that the application could be deployed to an ASP NET application such as SharePoint. SharePoint is becoming a dominant platform for collaboration, portals, business intelligence, integration and content management..

Microsoft offer SharePoint Foundation version for 2010 and 2013 so organisations that have a valid server license can start using several of the awesome SharePoint functionality for free.

For a features comparison between SharePoint Foundation 2010 and the other editions you can visit this site: SharePoint 2010 Feature Comparison

For a feature comparison between SharePoint Foundation 2013 and the other edition you can visit this site: SharePoint 2013 feature comparison

A deployment diagram for SharePoint looks very similar to the one for ASP NET

 For simplicity reasons I am leaving the different SharePoint deployment option out.

For instance, will the application will be deployed as a Feature Solution with farm or site scope?
Will the application take advantage of the new SharePoint 2013 application model, (i.e SharePoint Apps)

This simple deployment diagrams already got me on a design mode and I can see that some application component could be decoupled from our target platform be it ASP .NET or SharePoint.
So I came up with modified deployment diagram.

Please note that Service layer can be deployed on the same server where the Presentation and Data access layer will reside. I decided to put it in separate deployment node as it also could run as a self hosted server outside IIS

In this design the service layer could be implemented as a set of RESTFUL services. We could implement the application RESTUL Api using either WCF or the new kid on block "ASP NET Web API".  I tend to favour Web API as it has less over head than WCF and our default application protocol is HTTP anyway.  If the application was to support other communication protocols like raw TCP/IP or UDP then WCF would be my first choice.

For SharePoint this design would work well because the SharePoint client object model supports RESTFUL services.  The improvement on the design is that our service layer can be nicely decoupled of the hosting environment (i.e. SharePoint).