Feeds:
Posts
Comments

Posts Tagged ‘JavaScript’

Introduction

If you ever had to implement some kind of visual change in SharePoint, you know that, with previous SharePoint versions, this could be a challenge. Even SharePoint 2010 is spitting out HTML that makes website designers cry.

I installed SharePoint 2013 Foundation Preview this week. And I decided to take a look at the changes in HTML with some of my past branding projects in mind

Notice: Although I’ve implemented quite a few custom look and feels in SharePoint. I do not consider myself an expert in CSS, HTML 5 or SEO. But I do recognize bad HTML code. ;-)

<head>

First thing you notice is that the <head> section is much cleaner. It is better aligned, I only counted 2 JavaScript script blocks. All the other JavaScript code is nicely stored in external JavaScript files and (dynamically) referenced on the page.

There seems to be a lot of this dynamic registering of JavaScript files going on ( RegisterSodDep ). These JavaScript files only load when they are requested. This significantly reduces the load time of a web page. This function was also available in SP2010 but to my knowledge it was not used this much.

I’m also missing some hidden input fields. I’m not sure if this is by design or if it’s due to my freshly installed SharePoint and my lack of enabled features.

The _layouts/15/

They have added an extra version number in the /_layouts path.
Examples:

<img src="/_layouts/15/images/spcommon.png" />
<link rel="stylesheet" type="text/css" href="/_layouts/15/1033/styles/Themable/corev15.css"/>
<script type="text/javascript" src="/_layouts/15/init.js"></script>

A good move as it will probably make future backward compatibility easier to maintain.

Web parts

In previous SharePoint versions, adding web parts to your page results in nested <table> elements embedded in the page. Styling these nested tables is a handful. Luckily the tables made way for <div> elements.

One word of warning though. The web part title and body are still wrapped in 4 levels of divs. IMHO They could have simplified it even further.

Another example is that the HTML of the web part title is rather complex.

<div>
  <span>
    <h1>
    <nobr>
      <span>A web part title</span>
    </nobr>
    </h1>
  </span>
</div>.

Personally I see no reason for this complex HTML structure. Except maybe for some compatibility issues with some older browsers?

The body

No funky load scripts anymore on the body element. They are still there though. They are probably replaced with jQuery alternatives. For example the “#s4-workspace” style attribute is still updated dynamically with each screen resize.

The HTML in the body is cleaner. SP2013 clearly steps away from the table layout which is a good thing. I did notice some <div> elements with css classes like ms-table and ms-tablecell. ;-)

The deep nesting of HTML elements is still present in SharePoint 2013. Probably due to the extreme flexibility that SharePoint offers to modify and extend almost everything that is on your page.

Conclusion

In general the SharePoint 2013 HTML code makes a big leap forward. The nested <table> elements that were over present in older versions of SharePoint are gone.

Huge clean-up in the head section, controls are rewritten to use HTML best practice guidelines (example <ul> instead of <tables>) .

Yes there is still some optimisation possible but overall designers will have it a lot easier when applying a corporate identity on SharePoint site.

Read Full Post »

Introduction.


A requirement that I regularly see in a website specification is: “Make sure the user can only click the button once and display a confirmation box.”.
The extra challenge in ASP.NET is not to lose the postback functionality. In this short post I show you how can disable a button on the client-side while keeping the ASP.NET postback functionality working. We will also add a confirmation box to the button.

Step1. Our sample button

Create a default ASP.NET button and add a (postback) function (btn_Click in our sample)

 1: <asp:Button ID="btn" runat="server" Text="Start"  onclick="btn_Click" />

Step2. Disable after first click.

Next step is to add some clientside code (JavaScript) to disable the button as soon as it get’s clicked.
We do this by adding a small piece of JavaScript to the ‘OnClientClick’ property

 1: <asp:Button ID="btn" runat="server" Text="Start"  
 2:     OnClientClick="this.disabled=true;this.value = 'Please wait ...';"
 3:     onclick="btn_Click" />

Step 3. Make sure the postback works.

As you might notice the previous step broke the postback functionality. When you click the button, the button is disabled by the JavaScript but the C# function “btn_Click()” is not triggered anymore. To solve this we need to add the “UseSubmitBehavior” property.

 1: <asp:Button ID="btn" runat="server" Text="Start"
 2:     UseSubmitBehavior="false"
 3:     OnClientClick="this.disabled=true;this.value = 'Please wait ...';" 
 4:     onclick="btn_Click" />

The “UseSubmitBehavior” will add the correct (clientside) PostBack function to your button. Now the button gets disabled and the “btn_Click()” function in our codebehind gets triggered again.

Step 4. Adding confirmation box.

Final thing we need to do is add the confirmation box. Again we do this by using JavaScript. This time we put it in font of the JavaScript already in place in the “OnClientClick” property. We add “if (!confirm(‘Certain??’)) return;”. It tests if the user confirms. If the user does not confirm the executing of the JavaScript stops and the disable and postback code never gets triggered.

 1: <asp:Button ID="btn" runat="server" Text="Start"
 2:     UseSubmitBehavior="false"
 3:     OnClientClick="if (!confirm('Certain??')) return; this.disabled=true;this.value = 'Please wait ...';"  
 4:     onclick="btn_Click" />

Hopefully it’s helpful.

Regards,
W

Read Full Post »

I recently ran into a problem where my web part, that uses jQuery, didn’t work anymore on the SharePoint production server. After some investigation it became clear that it was caused by another  SharePoint feature that was enabled on the site.

This SharePoint feature used it’s own JavaScript framework that conflicted with jQuery. jQuery uses some keywords and expressions in a fashion that does not match with other libraries. jQuery Has foreseen this and has functionality in place to resolve this.  More information on how to solve this can be found here.
After applying these changes the two frameworks were working happily together.

For more detailed information about the issue I encountered see here.

Hope it helps.

Read Full Post »

Follow

Get every new post delivered to your Inbox.