20. January 2012 19:27
Hi all! May be you are already familiar with sharepoint 2010 script on demand feature. Recently I was playing with it and want to show some examples and explanations how it works.
There is a server control, that is responsible for rendering scripts on demand - ScriptLink .This control has 4 significant properties: LoadAfterUI, Name, OnDemand and Localizable.
- LoadAfterUI (if true) means that your script link (or script) will be rendered at the vary end of the <form> tag (when all other html elements already loaded). if this property equals to false, script will be inserted right after <form> tag. Internally, methods RegisterStartupScript and RegisterClientScriptBlock used. The only difference between these two methods is where each one emits the script block.
RegisterClientScriptBlock() emits the script block at the beginning of the Web Form (right after the
<form runat="server"> tag), while
RegisterStartupScript() emits the script block at the end of the Web Form (right before the
- Localizable – if true, sharepoint try to find your script under “_layouts/1033/”
- OnDemand – the most interesting property, indicates if we need this script load immediately, or if it should be downloaded on demand
Ok, some examples. Imagine we have script file myscript.js directly inside the layouts folder and we want to load it (OnDemand = false) . Its easy:
<SharePoint:ScriptLink runat="server" ID="sl" Localizable="False" LoadAfterUI="False" Name="myscript" OnDemand="False"></SharePoint:ScriptLink>
This action produces this output:
8. January 2012 08:53
If you are working with SharePoint you are using lookups a lot. SharePoint renders lookup field in list forms as html <select> element. And you may know, that if items count in lookup list become more than 20, something interesting happens with lookup render mechanism. In IE (and in IE only), html <select> become an <input> with image (complex select-like control). Consider following images:
|IE ||FireFox |
| || |
As you can see, lookup renders differently for different browsers. IE renders lookup as <input> and image, binds a couple of events to this controls to simulate auto complete behavior. This is pretty cool solution, but has its drawbacks: it works in IE only, you can’t style it, autocomplete appears when items more than 20 and you can’t control it. I've written small jQuery plugin to fix this.
There are two methods in my plugin: fixLookup and lookupAutoComplete.
7. July 2011 03:07
If you need to quickly get field internal name or type from UI, you can get it from any list form - new\edit\view. You must select html <td> element, that contains specified field value, and in html comments you can see field's display name, internal name, and field type. As on screenshot below, I use Firebug in Firefox:
Or Web Developer tools in IE:
7. July 2011 02:07
Recently I posted about accessing lookup fields in item event receivers and about some pitfalls when you are using it.
Next part is about using PeopleEditor (or people picker as it sometimes called). Let's add new field to our list and see what will happen in event receivers.
In AfterProperties you can see "7". "7"?! Why? Because SPFieldUser that we was added also an a lookup field. Lookup list for this field is a hidden UserInformationList that trackes a part of user-related information, such as login name, display name, email, and some other. "7" is id of user in UserInformationList. You can get SPUser object by using method web.SiteUsers.GetByID(id), or you can use SPFieldUserValue to get user.
In ItemAdded you can see that our lookup has a value - this a login name of a user:
But sometimes you may encounter with problem, when user may not in UserInformationList. I delete user from this list using this small PS script:
6. July 2011 03:44
Recently I was playing with synchronous item event receivers and lookup fields and found some interesting behavior in different situations. I'll try to describe some pitfalls that I faced when develop item receivers for SharePoint.
So, lookup fields. When you try access to a lookup field in such events as Adding or Updating you may to have lookup value. But AfterProperties always contain only lookup Id, if you want to get lookup value you must query item by id. Imagine you have a list named "Software", it has title field and category lookup field (now we have 19 category types in "Category" list). When we try to add new item in "Software" list in ItemAdding event we can see:
Where "18" is an Id of category. And ItemAdded:
So, when use class SPFieldLookupValue, in ItemAdding event LookupValue equal to null (in AfterProperties) and not null in ItemAdded(in ListItem).
Let's try to update this item:
Situation is very similar - in AfterProperties we have an item Id (LookupId in SPFieldLookupValue class, LookupValue is null), and value in ListItem. In ItemUpdated event as you may know we will have both lookupId and LookupValue. Be aware of this SharePoint behavior.