Cool HTML5 stuff to try out

I’ve been busy lately with changing work and working on some projects, but I would like to share with you some nice HTML5 ideas that may inspire you and give your better understanding into what HTML5 is now capable of doing:

Make a wind for your Lion

Keyboard with sounds

Pomodoro Timer  (Just like some of Chrome’s Apps)

CSS Logo Animation

That would give you some ideas on what can be done with HTML5, CSS3 alone, without the need for custom development. Interesting how we can use these techniques now to build fancy stuff on top of SharePoint either online or on premises with the capabilities now available to us to leverage these techniques.

 

 

ReadOnly Vs. Hidden in FieldRef

Ever wanted to know the difference between the “ReadOnly” and “Hidden” attributes for the FieldRef? If your answer was yes, then keep reading..

You may get confused when you try to set the properties for a field in case you want to reference it in a content type, basically you use FieldRef to reference fields in your content type, then you may wonder when to use the “ReadOnly” and “Hidden” attributes.

Similarities:

The reason that makes you consider these attributes is that if you want to hide the item from the NewForm.aspx page. Both will hide your column from this page.

Differences:

The difference here is that “Hidden” will hide your field completely from SharePoint, you will be able to use this field in code though (so you may use it like a property for the content type to store specific values that won’t be shown in the browser), but you won’t see it in browser, you won’t even be able to see the field when you want to modify the view for the current list, it’s Hidden (as its name says!).

ReadOnly will hide the column from the NewForm.aspx page (so it’s a ReadOnly), but you can always modify the list’s view to show this field. So it’s not Hidden 100%.

So never use Hidden in case you want to be able to view the field later in the list!

That was a quick tip that would clear things out for some people out there!

ng-show (or ng-hide) vs. ng-if

Here’s a fact I have found during my work on a SharePoint add-in with AngularJS, you might have read that ng-show does a similar work as ng-if in case you need to hide or show some markup on your page depending on specific condition, so ng-show and ng-if will both do the work, but with slight difference .. or is it a big difference?

The common thing that’s known about the difference between ng-show and ng-if is that, ng-show and ng-hide both will add the styling to change the display of the element to be “none”, so by changing the css for the element and changing the display property, ng-show will hide or show the element. The difference with ng-if is that it will remove the element itself from the markup if the condition is not met, and will return a clone of this element when the condition is met… But that’s not the only difference as well, and not the important difference..

What caught my attention is a difference that’s related to performance. Imagine you have a  table with many rows in your page, with checkbox that’s when checked will view an image related to the row. The thing is, if you’re using ng-show with an expression that evaluates to true/false, all images will always be downloaded in your browser, but you will not see them as they’re going to be hidden because the checkbox is not checked yet. However, when you use ng-if and it evaluates to false by default because the checkbox is not checked, the image will not be downloaded until you check the checkbox, which will be better for browser’s performance (Imagine if you have a repeating section with 100, if you use ng-show, all images will be downloaded to your browser right away, but if you use ng-if, only images that you check will be downloaded).

I hope this helps someone out there with their Angular work as it helped during the Add-in I was working on!

Update items that use Managed Metada column when a term is updated

If you worked with Managed Metadata columns in SharePoint, and tried to change the term’s value in the term store you will notice that the value of the new term is not reflected in your lists, this is a common problem with Managed Metadata, but not a problem at the same time.

The reason for this is, the terms used by the site collection are stored in a hidden list inside the site collection, it’s similar to the list used by variation to synchronize between source sites and target sites when using variation in SharePoint.

All what we have to do in this case is to call the method SyncHiddenList,

public static void SyncHiddenList(SPSite site)

As you see from the definition, we need to pass a parameter of our current site collection, and once it’s called, it will update all of your terms inside lists and libraries.

Get all documents from a Document Set Programmatically

Here is a quick post on how to get all documents from a document set programmatically:

//First getting reference to the list:

SPList myList= web.Lists.TryGetList(“ListName”);

if(myList!=null){

string strquery = “<Where><Eq><FieldRef Name=’Title’/><Value Type=’Text’>”  +           “DocumentSetName” + “</Value></Eq></Where>”;
SPQuery strcamlquery = new SPQuery();
strcamlquery.Query = strquery;
//getting reference to the document set item inside the list
SPListItem docsetitem = myList.GetItems(camlquery)[0];

//Now to loop through items in the document set

SPQuery itemDocSetQuery = new SPQuery();
itemDocSetQuery.Folder = docsetitem.Folder;
SPListItemCollection items = myList.GetItems(itemDocSetQuery);

}

That was a quick post, but I am sure this will be helpful to someone out there.

Writing timer job against Managed Metadata Service Application

Have you ever written a timer job in SharePoint to read from or writing to a term store in Managed Metadata, you might have done so and faced the error:

The current user has insufficient permissions to perform this operation

Even if you try to run the code with SPSecurity.RunWithElevatedPrivileges(), or with your own account from Visual Studio, it will still give you the same problem.

The thing is, that the timer job runs with its own service, which is “SharePoint 2010 Timer”, see the below image.

The user running this service has to have access to the term store administrators in Central Administration, see the image below:

Once permission is given here, you will start having access from your timer job to the managed metadata term store and create your desired term sets and terms.

Object reference exception when accessing farm properties

Here is a problem I had and it took me a while to know the reason behind it, it’s when you try to add a farm property using PowerShell, like this:

Now try to get the farm properties using the following command: $farm.properties, you will see the following result:

that’s great! You could get your property name and value without any problems, so now let’s try to get the farm property in code, shall we?

In visual studio type the following in your code:

String myProperty = SPFarm.Local.Properties[“MyFirstProperty”].ToString();

Baaaaaam, you will get: object reference not set to an instance of an object.

The reason is, although you can see the farm property in PowerShell when you type $farm.properties, you need to write the $farm.update() command after that in order to be able to use that property and to be visible in your code.

Hope this helps someone out there.

Extra column in Content Query WebPart not showing

So one quick tip..  I had a requirement to add an extra field for a CQWP, and map it to display a column inside my target list, Here is a mistake that took me a while until I figured it out:

So to add a new field, we modify both ItemStyle.xsl and the .webpart file to include our new field, right?

I have my field inside my list called: SecondLocation, so in our Template inside the ItemStyle.xsl, we add this field inside a div or any other html control we may need, in order to style it, like this:

<xsl:value-of select=”@SecondLocation”/>

Now we will add this field to the webpart itself, because it’s not there by default, so we export the webpart, and add this field to the “CommonViewFields” section, what I did is like this:

<property name=”CommonViewFields” type=”string”>
SecondLocation, Text
</property>

When I tried to view the webpart, I didn’t see my field displayed, Although the internal name is right, the field is written in ItemStyle.xsl, the field is added to the .webpart file, the thing is with the formatting of the xml for the .webpart itself, instead of writing the properties for the webpart on multiple columns, you should write it all on the same column, like this:

<property name=”CommonViewFields” type=”string”>SecondLocation, Text</property>