All posts tagged jQuery

LifeInSharePoint – Metro Weather WebPart

metroweatherwebpart

UPDATE :

Due to an update to the World Weather Online API to a new one, the WebPart is currently having issues raised in the comments. I am working on bringing you an update with the new API and also trying to include time information as well. If you are able to be patient I will bring this asap. Thanks.

Overview

After a couple of days tweaking, and adding some additional functionality, I am happy to release the first version of the Metro Weather WebPart. This WebPart was created due to the lack of (in my opinion) good looking weather WebParts available. The WebPart has multiple modes, built in caching, XSLT rendering and a great look. See below for the release and its features.

Features:

What it looks like:

Now you know the features how about we show you how the webpart looks when it is installed on the page.

Horizontal:

This mode shows the locations horizontally tiled from left to right and when you click on a specific location the forecast will fly out “Horizontally” to the right to show the day of the week, the weather, the temperature (in centigrade or fahrenheit) and the wind speed (in mph or kph).

weather_horizontal

Vertical:

This mode shows the locations horizontally tiled from left to right and when you click on a specific location the forecast will fly out “Vertically” to the bottom to show the day of the week, the weather, the temperature (in centigrade or fahrenheit) and the wind speed (in mph or kph).

weather_vertical

Horizontal Summary:

This mode shows the locations in a single fixed widget displayed “Horizontally” with prev and next buttons to the left and right of the forecast. The weather, the temperature (in centigrade or fahrenheit) and the wind speed (in mph or kph) is shown for each day in the forecast.

weather_summary_horizontal

Vertical Summary:

This mode shows the locations in a single fixed widget displayed “Vertical” with prev and next buttons to the left and right of the forecast. The weather, the temperature (in centigrade or fahrenheit) and the wind speed (in mph or kph) is shown for each day in the forecast.

weather_summary_vertical

How to use:

To use the new Metro Weather WebPart first download and upload the solution to your site collection. After you have activated the feature you are then able to add the WebPart onto the Page and configure the webpart to display the weather information of your choice.

The WebPart has the following properties that can be configured at set:

  • – This is the most complex property to complete. This is a comma and semi-colon delimited string which will configure the location that will be displayed, its colour and if required a different display name.
    • The string should be in the following format: Location{Display Name},Colour;Location{Display Name},Colour
    • Examples from the screenshot above would be: London,red;Las Vegas{Sin City},blue;New York,green;
    • If you emit the {Display Name} then the city name from the xml results will be displayed instead.
    • The avaliable colours are shown in the features above.
  • – This sets the number of days forecast that can be displayed. (The Free API enabled a max of 5)
  • – Before you are able to use the webpart you will need to sign up for an API key at http://www.worldweatheronline.com/register.aspx
  • – This is the XSLT path for the WebPart. The default setting should be: http://servername/Style Library/LifeInSharePoint.Weather/xslt/Weather.xslt
  • – Sets the display type of the WebPart. Horizontal, Vertical, SummaryHorizontal, SummaryVertical.
  • – Sets the temperature setting to either centigrade, or fahrenheit.
  • – Sets the wind speed to be displayed in either Mph, or Kph.

Download

To download this webpart please visit our Codeplex site and as always if you like it please leave a review, and if you find any issues or bugs either let me know via this site or the codeplex site.

Conclusion

I really hope that this webpart comes in handy for the SharePoint community. Really hope you all like it :)

jQuery Collapsable Quick Launch – Plugin Update & Cookie States & 2013 Compatibility

Overview

Christmas is nearly with us and it has been a long while since my last post. To try and give some people a little Christmas cheer I am releasing part one of my new set of jQuery plugins for many of my Quick Tips that I have posted. Today’s update is to the ability for a user to hide / show the Quick Launch menu. Although the previous version worked well, there were a number of requests for new functionality which I have integrated into my new version. The new version also makes configuration MUCH easier and friendlier for non-techy types.

New Features:

  • Plug-in Architecture based on jQuery Boilerplate
  • Ability to set default state of the Quick launch (HideOnDefault)
  • Quick launch state is now saved across page views using Cookies. This can be turned off.
  • Re-written code.
  • Fully configurable for various scenarios (Have tested on OOTB & Custom Masterpages)
  • 2013 Compatible. I can confirm the plug-in works on the OOTB Seattle.master with no code changes (only plug-in configuration).

How to use:

The quick launch plug-in can be used and applied as follows:

Options:

The following default options are available:

No CSS is required for the plugin and the main plugin selector should be the side navigation div that you are hiding. So in the case of SharePoint 2010 this will be “#s4-leftpanel”

Full Usage (2010 / 2013)

2010 Full Usage (OOTB Masterpage)

2013 Full Usage (OOTB Masterpage)

Hope you enjoy this plug in and as always if you have any issues please let me know.

Download

Developer Version : jQuery.LISP.quicklaunch.js

MinifiedVersion : jQuery.LISP.quicklaunch.min.js

Quick Tip – jQuery Collapsable Quicklaunch for SharePoint 2010

accordion_hide

 

 

Another day, another jQuery Quick Tip.  Today we have a piece of jQuery that will enable an end user to hide the Quicklaunch from view and free up some additional space if you have a lower resolution.  As with my other Quick Tips the following code uses the OOTB v4.master so may not work if you have customised your design. (Changes to selectors should be all that would be required to get it working with your own design)

The script above is not much more complicated than previous ones but as always i will go through it piece by piece so you are clear as to what is going on.  The first line is getting a hosted version of the jQuery library, obviously if you have this locally then it may be worth updating this reference appropriately.

The first six lines of code are to setup some variables that will be used during the rest of the script.  We first get a reference to the main Right hand content div which in the case of the OOTB masterpage is the s4-ca classed div.  Next we save the size of the left margin of this div so that it can be used later.  We then set the LeftArea div for the item which will be hidden and also define the size of the left margin when collapsed which is what line three is for.  Finally we have two variables that define the expand and collapsed images.

The next line is quite a long one but its nothing complicated.  What we are doing is to the Defined MainArea we are adding our image with a hyperlink on it which is positioned at the top of the parent container.

This final piece of code is the core of the script and contains the click event handler for our dynamically added code shown above.  We first define the click handler, then we toggle the configured LeftArea so that it is hidden.  Now if we stopped there we would have hidden the quicklaunch but the page would not expand to provide any more room.  To fix this we then need to adjust the MainArea left-margin.  Line four first checks if the left section is visible, and then if it is we set the MainArea margin-left to the configured NoLeftMargin otherwise we “reset” to the left-margin that was set on load.  The final two lines updates the image to show the collapse or expand image depending on the status of the LeftArea.

That’s all there is to it.  I hope like previous snippets that this will be useful for someone and if you have any recommendations or suggestions of new functionality that you would like to see then please let me know.  As always your positive comments are always welcomed and keep me working on new content for you.

 

iGoogle UI for SharePoint – Part Five : SharePoint 2010 Integration

part5

Series Content

  1. Part One – Overview, Concept, HTML Structure & jQuery Basics
  2. Part Two – Dragging, Dropping, Sorting and Collapsing
  3. Part Three – Saving WebPart states using Cookies
  4. Part Four – Control Adaptersc
  5. Part Five – SharePoint 2010 Integration – Current Article
  6. Part Six – Bringing it all together
  7. Bonus – Saving WebPart States using the Client Object Model

Overview

In Part Five, we will take the previous posts and show you how to get it into SharePoint 2010. I’ll show how to create the Visual Studio Project, and then deploy the assets into SharePoint to create a working example.

Visual Studio Project & Assets

For this post will be using Visual Studio 2010 as our development platform. As part of my default development build i like to have the following VS plug-ins installed.

For this post, we will be using Visual Studio 2010 as our development platform. As part of my default development build, I like to have the following VS plug-ins installed:

SPI’s & Features

Our project will contain the following SPI’s (SharePoint Item) to deploy the required assets.

The Project will contain only a single feature which will deploy all the assets required for the iGoogle interface. This will be a SITE scoped feature with an event receiver to manage the addition of values to the compact.browser file.

Visual Studio

The first step for this and pretty much every other SharePoint Project is to fire up Visual Studio 2010 and create a new SharePoint 2010 Project. Call the project LifeInSharePoint.iGoogle. On the next screen we would also like to create this as a FARM solution. Sandbox solutions will not work as control adapters cannot be deployed using a Sandbox Solution.

Now that we have a project created, we first need to create some folders to contain our SPI’s. I like to organise my folders in a manner that I feel makes it easier to understand, so I will first create a Common folder which will contain a sub folder called ControlAdapters. NOTE: I do not have spaces in my folder names as visual studio will replace them with “_” in namespaces. I will now create another top level folder called Root and within this I will create another folder called Content. These two folders will contain the module that will deploy the iGoogle.aspx page and place WebParts onto the page. To ensure that we can access the images, js and css from anywhere, we will place them in the /_layouts folder. To deploy these to the Layouts folder from Visual Studio is very simple. Firstly you will need to right click on the project in Visual Studio > Add > SharePoint “Layouts” Mapped Folder.

This will create you a project named sub folder which we can use to place our css etc. Once this has been done your folder structure should look like this.

Now that I have the basic folder structure, I will now create a new a new class file for my ControlAdapter called WebPartRenderControlAdapter.cs. For the info on how to create and what goes into this class file, please see the previous post where I go into a lot more detail. iGoogle UI for SharePoint 2010 – Part Four: Control Adapters.

The next step is to add the CSS, JS, and Image that we created in the first three parts of this blog series. (These will be available at the end of this post) in the supplied zip file.

Adding Content & Pages

Next, we need to create the root content module. This module contains two items. The first is the Elements.xml file which will contain the XML required to deploy our page, and the second item is the default.aspx page which we will provision. This default.aspx page contains the HTML snippets from the first couple of posts in this series as well as the references to our javascript and css which we are storing above in the /_layouts folder. Below is a snippet from within the default.aspx page.

As you can see I have made some small changes by placing our three columns within a table to keep things nice and neat. The script references have also been updated to point to our deployed assets. The elements.xml file is very simple. It takes the default.aspx page and deploys it to the root of the current site creating an iGoogle.aspx page at that location.

As you can see there is not a lot to it. We are setting the name of the deployed file to iGoogle.aspx and the Url in this case is the relative url within the project, NOT the location it will appear on the site, a common mistake I have made many times. If you wanted to place the page in another location you can modify URL and Path attributes in the <module> tag to point to another location. Since we want to place the page on the root, these are left blank.

Adding WebParts

The final addition to this elements.xml file is to add some default WebParts on to the page. For this demo we are going to use some Content Editor WebParts which will have some dummy Lorem Ipsum text within. (You can replace the xml with some other WebParts if you like, as long as you know the XML) The XML element you need to add WebParts on to the page is the <AllUsersWebPart> Node. This node has attributes which we use to define the order on the page, as well as the WebPart Zone the WebPart is to appear in. The Snippet below shows a single item.

You can also see from the code above that we are surrounding the WebPart XML with a <![CDATA[]]> tag which means that the text within will be ignored by the XML Parser.

Creating the Feature

Now that we have nearly all the pieces of the puzzle, the next step is to create a feature in our solution which will deploy the items to SharePoint. You should notice in your project there is a Web scoped default feature called Feature1. We need to rename our feature to something more meaningful, so in the Solution Explorer right click and rename the feature. My preference for naming Features is as follows:

SCOPE.ProjectName.FeatureName

The reason for this is that there is no quick and easy way to know the scope of a feature from glancing at the solution explorer as all icons are the same. Therefore in our solution the feature will be:

SITE.LifeInSharePoint.iGoogle.Assets

The next step is to double click on this feature and it should open the feature management screen on the left side of the window. Within this window you are able to change the Display Title and Description as well as manage the items in the feature. We will call our feature LifeInSharePoint.iGoogle, the description can be what ever you please and the Scope should be set to SITE. Finally add the Root.Content.Pages SPI into the feature and we are nearly complete.

Writing the Feature Receiver

For those who remember the last post, the control adapter requires an entry into the compact.browser file. This entry registers our control adapter for use and it would be very useful if this was added automatically as part of our deployment. To do this we will need to create a small feature receiver to do this for us. To add a receiver, right click on the feature and click the Add Event Receiver link.

We are only going to manage the addition of the code to the compact.browser and not the retraction from the solution. This can be added to your solution if you wish but to save time I will ignore it.

Our first step is to create two string constants which will contain the Control Adapter Type and the Assembly Name of the Solution. The Assembly name will only contain the first part as the full assembly name will be retrieved later through reflection.

The next step is to uncomment the FeatureActivated method and add the following code in.

This code simply gets the current Site Collection from the features property collection and then passes that SPSite object to the UpdateCompactBrowser method which is explained below in the code comments for each line.

If we save all the items in the project, we are now ready to deploy our project to our site. When the feature activates it will run the code above which will make the necessary changes to the compact.browser file and our solution should work as expected.

Deployment & Testing

To deploy the solution we need to build the solution by right clicking on the project and clicking Build. After the project has been built and no errors are found, we can then deploy by again right clicking on the project and clicking Deploy. The default deployment configuration in Visual Studio will automatically activate the feature on the destination site. After deployment, navigate to the site and view the site collection features. We should see our feature deployed and activated.

If we now navigate to the root of the site collection and change the url to http://[SITE URL]/igoogle.aspx, then you should see our newly deployed interface with 5 different CEWP with some Lorem Ipsum text.

You should now be able to drag and drop these WebParts around the page, close, and change the colour. When you have finished and navigate away, refresh the page and the WebParts will remember their states. If you edit the page you will see how the Control Adapter does not render in edit mode enabling you to add new WebParts. You can see below that I have added a new Image WebPart to show how easy it is to create new “Widgets”.

NOTE: It is important to understand that this interface is designed for “Rollup” style WebParts. Due to how SharePoint 2010 and the Ribbon works with WebParts you may find some OOTB WebParts do not function fully. (Calendar WebPart, ListViewWebPart) The reason for some WebParts not working is that we are replacing the Chrome around the WebParts with our custom HTML (ControlAdapter). Many of the required ID’s etc are removed and therefore the Javascript that works with the Ribbon & Ajax fails. I am working on this and will post an update when I find a solution.

Summary

In this post we have outlined how to get the iGoogle interface into a SharePoint environment. Using a Visual Studio 2010 Project we have deployed css, images and javascript, created and deployed a Control Adapter, and added a page full of WebParts on to a site. I hope this post gives you a stepping stone on how to implement something similar on your SharePoint Deployments. Below I have uploaded a link to my Solution ZIP file that you can use and test on your environments. I have not done lots of cross browser or different environment testing of the solution so should you find an issue let me know and I will try my best to find a solution. In the next post I will show you how you can use the techniques shown in this series to come up with some innovative designs and implementations.

Download

LifeInSharePoint.iGoogle.zip

Quick Tip – jQuery click to expand / collapse Quicklaunch – UPDATED 20/06/2012

jquery_collapse_accordion

Hello everyone, following on from the previous Quick Tip I have yet another cool little snippet of jQuery code to enable a manually collapsable quicklaunch.  Many users who have downloaded my Metro UI masterpage commented if there was a way to have the hover quicklauch accordion replaced with a clickable version.  Well your requests have been answered and below is a snippet that will work on any v4.master page.  I have included some comments within the source code to help you out.

I hope that this code is what you were hoping for, and i will soon be updating the Metro Masterpage for Farm Solutions to include an option to choose your accordion type and a Metro UI version of the code.

As always comments / issues always welcome :)

UPDATE 20/06/2012.

Thanks to Anastacia for pointing out the issue with the script in Firefox.  I have updated the script to fix this issue by placing the anchor in a different location and updating the rest of the script. Please use the new script above which solves the issue.  Chris