Sharepoint EvilGenius: February 2010

Wednesday, February 17, 2010

Creating a Blog Suite as a Feature (Intro)

WHAT EXACTLY IS A BLOG SUITE?

So, I was asked to create a blog-like suite of components that could be added as a feature or series of features to an existing site or subsite. The suite was to have a blog, a contacts list, an events(calendar) list, a quicklinks list, and a component that allows users to submit a future blog topic and allows them to vote on a series of topics to blog next. So this to me is a Blog Suite or as the customers wanted to call it an electronic communications suite. The customer will get their wish ;-)

The customer came prepared in this case with a fully working prototype of the look/feel they wanted in an access database. My job is to create a Sharepoint solution that mimics this access solution. I felt a challenge was coming and it was exciting.

So, I started thinking about what I wanted to do to make this as seamless as possible. Initially I created a blog site using the OOB sharepoint template and looked at some of the things that it does and how it looked. This was not going to work the way the customer wanted and I could not just make it a subsite. However, I could use the Sharepoint Solution Generator tool or the (SPSource) tool to pull out the list schemas of the blog site. Or I could create custom lists in a temp site and do the same thing.

I decided that I needed three lists for the blog part and then a separate list for the contacts, quicklinks, and events sections. So in total there will be 6 lists for this solution. My first task was to decide if I wanted to use list templates as mentioned above or if I wanted to create the lists programmatically. I opted for the latter in this case. I decided that I will create a feature in Visual Studio using the VseWss 1.3 extensions. I will add the feature with a feature receiver and this feature receiver will do most of the work in programmatically creating the lists that I need and adding the fields that I need to make it work. I decided to also add a module that would add a webpart page to the root of the site where the feature is activated. This page is going to have a custom webpart that I will add later.

In my next post on this, I will post my first steps in creating the feature and the lists.

First Test of adding html code

<html>
<head>
<title>Blogger Code Test</title>

Wednesday, February 10, 2010

jQuery Forms Replacement In Sharepoint (Phase III)

Okay, now it is time for a few updates on what I have been able to do and what my final solution is going to look like including the reasons I chose to go that way. In the last post on this topic, I talked about building the forms either with a Visual Studio webpart or a Dataform webpart from Sharepoint Designer. I talked some on what I had done on the Visual Studio side and now I will talk about what I did on the other side. First I again create a webpart page to add the webpart to and for this form I wanted to use it for adding new items to a custom task list that I had created. So I have a page and the list so I then navigated to the page in Sharepoint and chose to edit the page. This allows me to add a webpart and this when it really hit me to try something different. I added a content editor webpart. This is a very powerful webpart. I then used Sharepoint designer to create the html of a form using standard html controls and pasted those into the source editor of the webpart. Now I have a page that has controls on it and I changed the location of the javascript to the actual PlaceHolderMain content area of the page. This is the javascript that does all the work for getting the data from Sharepoint or updating the data depending on what I am doing. Again I am using the SPServices jQuery library and it really is neat how fast it is at getting and setting the data. This form was very basic as there were no special controls really. It just had a few text boxes and a couple of select boxes. This works great and is a great way to build small forms for displaying and updating certain pieces of data. I am still working on creating a code with code examples but this may be a few weeks from now. As I said, this does work and I bet I could even get this to work for inline editing of some items directly in the forms or maybe popup a window that does it. Again very useful and I like it. Now, for the environment that I work in and the tough restrictions placed on it, there are some things that I really can not do in our production environment. The main thing that we are not allowed to do is connect Sharepoint Designer to the site. This really makes it harder to update things or to build webparts that you do not have to export and import. As I mentioned in an earlier post, we have to provide solution packages and we have to have as much of the solution as possible in the package and we use Visual Studio for this. With that said, I chose to continue to create the forms using VS by creating a .ascx page that has the server controls on it. Using the VseWSS 1.3 extensions I add a new webpart to my solution and in the code-behind page, I attach the .ascx page and get a handle to all the controls. I also connect up the list to this form and prefill the form with the data. This form of course still renders standard controls and I can still use jQuery to do any updating of the data. This method makes it easier if we need to update the form or change it. I do hope to get some code up here soon, but until then, please let me know if you have any questions or feedback. If something is not clear please let me know!

Saturday, February 6, 2010

jQuery Forms Replacement In Sharepoint (Phase II)

Okay, so in my last piece on this topic I tried to layout several options or paths I could take to accomplish my end goal. At the time, my end goal was to replace my Sharepoint forms with jQuery forms. Over the past few days I have done a lot of experimenting with those options that I had laid out in the previous posts. I will now discuss what I have tried first and then what I think I will try next as another approach. I think I will mainly point out here two things. The main purpose of doing this at all is to avoid all of the postbacks to the server and this particular approach requires replacing the forms with custom forms. With that being said let me begin. For my first test, I wanted to replace the form that users get to when they go to the My Settings section of SP. This is usually found at the top left where it says Welcome (whomever). This dropdown allows you to get to that option which will take users to the userdisp.aspx page if they have the correct permissions. We decided that users should be allowed to change certain options here and we also had a lot more fields for them to fill out. The two main issues were the fields we did not want them to touch and the annoying normal 2 column format of the form which leads to scrolling. So I needed to replace the form or do a lot of other things to make this happen. I chose to replace the form with a custom form. I did not however replace the application pages, I just made a new page and make the users go to that page instead. Here is how I did that. (Remember from the earlier post that I have to make this as a solution package in Visual Studio (VS) as that is a requirement for portability to other locations from the customer.) First, I copied the default.aspx page to a new page called Employees.aspx. I did this mainly because I needed a webpart page to hold my form. This means that I am not solving my popup idea at this time but I am choosing to utilize the real estate of the PlaceHolderMain section of the masterpage. So now I have a page to put my form on. Now, there were basically at this point 2 options I could take here. One option was to build a custom webpart form and drop it on the page and the other was to create a custom webpart form on the page. I know those seem like the same thing, but the difference is how I create the webpart forms. I can build a .Net webpart in VS which allows an easy path for a code-behind page, or I could create a dataform webpart in Sharepoint Designer (SD). I know how to do both of those options but the first choice I made was to go with the VS option first to see what all I could accomplish with that. So, yes, this does not sound like jQuery and I do plan on getting to that but I wanted to show you how I get there and what I was able to do. So, I firstly created my aspx page and now I need a form with controls on it. I did this by creating an ascx user control page that just had a table and the form controls laid out the way I wanted them to be. This meant I could design the form with more columns and make it wider so there was no need to scroll. I also had to provide a cascading dropdown option for the customer so that users could select their organizational structure based on where they worked. This is like a Department, Division, and SubDivision rollup. I decided that this rollup could be done in a single list with the 3 fields tied together. Basically this means that you have an entry for each subdivision including its primary division and department. Now I have my controls so I needed to have a webpart to put them in. In VS I just added a new webpart to my project and this creates the code-behind class file that I need. I used this file to call the ascx page which is placed into the controltemplates folder of the 12 hive in a subfolder. I now have a form with controls that I can use. This is where the fun starts I hope! If you are following along this far you may be thinking that I have taken a long approach to this and it does indeed seem to be that way. I just had a feeling that I could do something with this that would be cool. I was right so lets press on. I purposely ensured that I did not have the autopostback option turned on for any of the controls on the form. Using c# I also added onchange events to a couple of dropdown (select) boxes. When an asp dropdown control is rendered in this case, it is rendered as a select html control. The onchange events are stored in the additionalpagehead content section of the Employees.aspx page. The codebehind page will prefill the options from the UserInfo list if they are there. It is already drawing the form so this is a good thing in this case. The Department dropdown box is filled with just the departments and it has the client-side onchange event attached! The event utilizes the SPServices jQuery library to to fill the second dropdown box with the divisions of whatever department is chosen in the first one. This second one also has an event to drive the 3rd select box. The form has a button that also uses the SPServices library to save the data back to the UserInfo list! This is pretty cool and very fast and the page does not refresh! Eureka I say! One note here is that the SPServices library does have cascade dropdown support that I may utilize in the second approach which I will try next. This means that my next approach will be to user Designer to create my forms to add to the Employees.aspx page. This means that I will get to utilize SP controls and see what I can do with them!