SharePoint 2013 Content Editor – zero width space characters

Sometimes, the content editor web part of SharePoint 2013 adds unwanted characters to the text within it. You check once, twice, remove any unnecessary line breaks, spaces etc., but after saving or in the HTML source of the page you find these weird characters: ​ – the zero width spaces (& #8203;)

They can mess up your CSS layout, and frankly, I have not found a solution to force SharePoint not to insert them.

One possible workaround would be to remove them with a library like jQuery, e.g.

[javascript]

$(’.ms-rtestate-field’).each(function(index,element)  {
var theeditor = $(element);
$(theeditor).html($(theeditor).html().replace(/u200B/g,”));
});
[/javascript]

The selector applies to the content editor webpart of SP2013.

Hope this helps.
Łukasz

ASP.NET: asynchronous calls to session-enabled web service methods

Howdy,

This time a small hint for those of you that are using jQuery and/or AJAX methods to connect with an ASP.Net web service, and the web service is using Session variables (web methods with [EnableSession=true] attribute).

I have been using this approach for some time, since I needed to persist some data for users.

However, when it came to performance tests, it occurred that the AJAX calls weren’t really asynchronous. The tests revealed that each next call waits for the previous one to finish.

The reason is quite simple and is one of ASP.net’s limitations: the first request gains exclusive access to the session and its variables, and thus prevents execution of next request until the current one completes. My approach was wrong and it took a while to discover the cause. Maybe if I had read the last paragraph of this article  first, it would have been easier 😉

So, for having better performance of concurrent request in a similar architecture, one would have to either use other ASP.net methods for persisting state (like Cache object), or write a custom solution.

Hope this helps,

Łukasz

Posted from WordPress for Android

Maintain selected tab position upon postback (jQuery UI Tabs)

Hello,

jQuery UI is a very nice add-on to the standard jQuery library. It provides us with out-of-the-box interactions and client side effects for a rich web application experience. One of the interesting effects are the jQuery tabs. They’re used to split the content into sections and be able to switch between them without having a postback, and also to spare some space within our web page.

The interaction is purely on the client side, so after reloading the page the tab which we selected as last isn’t maintained. What if we have, for example, a file upload control within one of our tab sections? After uploading a file (postback), we lose the focus on the tab in which we were previously.

But the developers of jQuery UI provide us with a couple of methods and events, which we can use to do some kind of workaround for this issue.

We need to have a document element which could store the selected tab index. We can use an input hidden field, value of which would be posted together with other data during page postback. So, let’s put it into our page, setting it’s value declaratively to 0 (the index of the first tab – default selection):

<input type="hidden" value="0" id="theHiddenTabIndex" />

Having the ID of the element, we can set its value from the client side script. Using the show event of the jQuery Tabs (fired when the tab is changed), we can do this at runtime:

$('#tabElmtId').tabs( {
  show: function() {
    var newIdx = $('#tabElmtId').tabs('option','selected');
    $('#theHiddenTabIndex').val(newIdx);
  }
 });

As you can see, when the event is triggered, the currently selected index of our tabs is being stored in a variable (line 3), then assigned as a value of the hidden input field. Now the postback can be performed but the next question is how to tell the tabs control to start from another tab index than the default 0.

First, on the server side, we can use the language which we prefer in order to fetch the value of the submitted hidden input field. For example, in ASP.net, it could look like this:

String hiddenFieldValue = Request.Form["theHiddenTabIndex"] ?? "0";

Now we can put javascript into our page’s source in order to tell have this variable also available for client side scripts:

   1: StringBuilder js = new StringBuilder();
   2: js.Append("<script type='text/javascript'>");
   3: js.Append("var previouslySelectedTab = ");
   4: js.Append(hiddenFieldValue);
   5: js.Append(";</script>");
   6: this.Header.Controls.Add(new LiteralControl(js.ToString()));

The one thing important about this is that it should be injected before the jQuery Tabs are initialised. Now the remaining task is to tell jQuery to use the javascript variable in order to set the selected tab upon loading the controls after postback. We can use the selected option of jQuery UI Tabs in order to assign this value:

   1: $('#tabElmtId').tabs( {
   2:     show: function() {
   3:         var newIdx = $('#tabElmtId').tabs('option','selected');
   4:         $('#theHiddenTabIndex').val(newIdx);
   5:     },
   6:     selected: previouslySelectedTab
   7: });

The only thing that changed from the previous Tabs initialisation is the line 6, where we assign the javascript variable to the selected option.
Now the tabs position should be postback-proof.

Happy jQuerying!