Gorgo.Live.ToString()

Mariusz, Gorzoch tech Blog

Archive for November 2009

Omniture, statistics and stuff around that

leave a comment »

Last week I’ve attended Omniture Training in London. When I was going there I thought that this is quite simple solution just to gather some statistics. What I found there, was quite surprising for me as this is not a tool but a powerful engine with quite impressive interface, which let you grind statistics data around your site and throw them into very fancy and reach reports.

The base concept is like that:

1. You agree on the business requirements/reports you need to take out from Site catalyst. In this stage you are working with dedicated consultant from Omniture, who help you understand how their engine is working and based on the information you are giving him, his creating some proposal of implementation (as an output you will get PDF document describing you all business questions and excel file which described variables used in your implementation and what those variables means for your site)

2. You set-up special JavaScript on your page/pages and set-up configuration values in it, based on the implementation definition done with the consultant. This script looks like this:

<!– SiteCatalyst code version: H.15.1.
Copyright 1997-2008 Omniture, Inc. More info available at
http://www.omniture.com –>
<script language="JavaScript" type="text/javascript">
    s.pageName = “<something which identify you page in the unique way>”
    s.server = “<host header,server name>”
    s.channel = “<1 level of your site hierarchy>”
    s.prop1 = “<2 lecel of your site hierarchy>

   …. (some other variables, depend on your implementation details) …

    var s_code = s.t(); if (s_code) document.write(s_code)          
</script>

<script language="JavaScript" type="text/javascript">
    if (navigator.appVersion.indexOf(‘MSIE’) >= 0) document.write(unescape(‘%3C’) + ‘\!-‘ + ‘-‘)
</script>
<!–/DO NOT REMOVE/–>
<!– End SiteCatalyst code version: H.15.1. –>

your scripts will look more or less like this, but details (s.prop1,s.prop2 and few other variables) will depend on the implementation details.

3. Once you set-up this script on your page, then this site, each time user will visit it, will send information to Omniture server based on the variable settings. Omniture is using this data to create different reports, which can be seen in different fancy way, send by email and even I wouldn’t be surprise that there is some option to sing the song about them (their UI is really powerful).

If you decide to go for this, then I would suggest to you to pay a huge attention to point 1. This is extremely important to understand what Omniture is, how they gathering data and how your system need to be set-up for that. I would say that this part of entire process takes something like 90% of everything. As soon you understand this, then you just need to place their script on your site, set-up 5-10 variables (depend on your needs and page where you are implementing it) and you are done.

happy omnituring…

Advertisements

Written by Mariusz Gorzoch

27 November 2009 at 16:30

Posted in Bez kategorii

PET – let’s make it simple

leave a comment »

If you start with publishing, then on the beginning you will be amazed about all the goodness it’s brings. After a while you click the option “Site actions –> Create page” and you again amazed about the option you get there… and here pop-up the problem… you see the nice advance toolbar on the top of the page and you are starting to ask you an questions : what for those all options are… there is also even worst question : if I don’t know what to do with those option there, then how the hell my users will know how to use them ?… yep… this toolbar at first approach (especially at organization, when people are starting to use SharePoint) has to many options and quite new user can get lost quite fast. This happened in our environment, were the only button users were using here was “Publish”.

To address this problem I’ve created quite simple wsp solution, which you can deploy to your environment and instead of very advance PET toolbar:

you can use a little bit simpler one, which look like this:

Believe me or not – users will thank you for that, as they know what to do with those buttons, 😉

On the end of this post you can find link to “zip” solution written in Visual Studio 2008. In general this solution is around concept to replace “CustomEditingMenu.xml” and “CustomQuickAccess.xml” files located inside “_catalogs/masterpage/Editing Menu/” at root site collection level. This concept was described very nicely by Andrew Connel in his book SharePoint 2007 Web Content Management Development. In addition if you look at Microsoft site : http://msdn.microsoft.com/en-us/library/aa674506.aspx , then you can also find quite good reference about that.

In the nutshell what this solution is doing:

  • After deploying wsp package and deploying it, you will get new feature at site collection level
  • When feature is activated then it is backup current  version of those files with the pattern <filename>_CurrentDateTime and replacing those custom files with the one, were additional/advanced option are turned off
  • When feature is deactivated, then we making backup of current files (in case someone tweak them up) and restoring the one we backup during activation process.

Here you can find customization I’ve done to those files:

CustomEditingMenu.xml

<?xml version="1.0" encoding="utf-8" ?>
<Console>
  <structure>
      <ConsoleNode ConfigMenu="Delete"  ChangedNodeID="saPageSubMenu"/>
      <ConsoleNode ConfigMenu="Delete"  ChangedNodeID="saWorkflowSubMenu"/>
  </structure>
</Console>

As you can see what we are doing here is just to asking SharePoint to remove “SubMenus” we don’t want to show.

CustomQuickAccess.xml

<?xml version="1.0" encoding="utf-8" ?>
<Console>
  <references>
      <reference TagPrefix="cms" assembly="Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" namespace="Microsoft.SharePoint.Publishing.WebControls.EditingMenuActions" />
  </references>
  <structure>
    <ConsoleNode Sequence="0" Action="cms:SavePublishingPageAction" DisplayText="cms,console_savechanges" ImageUrl="/_layouts/images/saveitem.gif" UseResourceFile="true" ID="saSaveChanges" />
    <ConsoleNode Sequence="100" Action="cms:DeleteAction" DisplayText="cms,console_deletepage" ImageUrl="/_layouts/images/delete.gif" UseResourceFile="true" ID="saDeletePage" />    
      <ConsoleNode ConfigMenu="Delete"  ChangedNodeID="qaCheckin"/>   
  </structure>
</Console>

and here we adding new buttons based on definition for those action located inside file “EditingMenu.xml” placed at “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\EditingMenu” folder.

Here you can find “zip” of Visual studio 2008 project: PublishManuSoluton.zip, have fun.

Written by Mariusz Gorzoch

13 November 2009 at 11:46

Posted in SharePoint

Custom publishing page layout

leave a comment »

Some time ago I was asked by the business to create custom “Article solution” and during the process of creating it I’ve created this simple tutorial how to do it. If you are interested then have look at it. The steps provided here are just to give you a fast snapshot what was done in particular step and for what you should pay your attention. If you want to dive into this solution, then I encounter you to download it thru the link provided on the end of this page.

so, let’ start:

1. Create empty class project in Visual Studio (I’m using version 2008) and reflect structure of the folders as shown on the picture bellow (I found good practice to fallow this structure as it make everything more clear and easy understand when it comes to deployment)

2. Now we will go create definition of Content type which will be used as a base to the custom publishing pages we will create. In addition to pure CT definition we will also add event receiver class, which will be fired-up on the “new item adding event”

Important things to note here are:

– ContentType ID need to be build on special pattern as this content type need to based on the “Page” CT. As this is so, ID of this content type need to start with “0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF39”. Our ID was build by adding to this ID, “00” + our private ID (generated one thru tools->Create GUID) “C1BE2D721C524e22923F09AF6C884540”

– In case you need to reference some predefined Microsoft fields, then go to : http://msdn.microsoft.com/en-us/library/ee413858.aspx and take field id from there (this is quite good reference for predefined fields)

In addition to creation this definition I’ve also added “Article02CTEventReceiver” class. For now it is empty, but I prefer to add it in case I need it later (so I don’t have to mess with XML). Here is the content of the pure definition of “Event Receiver” class:

3. If we defined CT definition for the page, then now we need to create layout which should use this CT. To do this you need to create two files “aspx” and “cs” (code behind) one. Of course creation of code behind file is not required as this is only required in case you need to do some behind stuff. I’m trying to do this all the time, as it easer for me later on to just put some code in case I needed. Here you have “aspx” page:

going from the top of this file, we are doing: (a) registering code behind file (so we can do some stuff with this page in code, (b) registering all controls we could possibly use, (c) we are registering our custom control (this is an example how you can implement your own custom control and bind it to field defined in CT), (d) creating the actual page layout.

On the code behind file you can not find to much, as this is just pure definition:

of course you can place what ever you want as this is normal ASPX page.

4. Now we adding web part artifact, which will let us to place a button on the main page, which will allow user to create new page based on our layout. For that we need to create to additional files “Article02ButtonWebPart.webpart” (it will contain definition of web part) and second one “Article02ButtonWebPart.cs” (it will contain code to render our web part and do logic required to create page). Web part definition file will look like this:

and code file looks like this :

(entire code for that you will find on the end of this post)

What can be tricky at this point is the way how we create new page based on our CT definition. This is done by creating new page layout and providing SPContentTypeID object which is build with use of the ID of created by us Content Type.

please notice how we retrieving page layout. This need to be done in this way, as our CT ID in particular list instance is different then the one we give to this content type. This comes from the way how Microsoft implement attaching of CT to lists. When you are adding CT to list, then it is working in the way, that SharePoint is doing copy of you CT in the background (with ID equal to your CT ID + Guid.New() on the end). This way they keep reference to the original CT definition and maintain copy of it inside list. So in case you do some changes around CT to this list, this will not brake global definition of it. Of course this comes with the cost, but this post is not about that (you can find plenty info on the net around that)

let’s move forward…

5. Implementing custom bound control. Create new file called “FielUploadControl”. this file should looks like that:

What is important to know here : (a) This class need to inherit BaseFiledControl, (b), if you need to have custom display for this field (and want to), you need to overwrite method “RenderFieldForDisplay” and “DefaultTemplateName”. (c) DefaultTemplateName need to return your class name. For more details, have look here : http://msdn.microsoft.com/en-us/library/aa981226.aspx <- this is a good reference how to build your own bound controls.

Ok, we are almost on the end. Now we need to pack this entire stuff… so let start with

6. Elements.xml

as you can see we are referencing here our “ASPX” page (and setting associated with the page Content Type ID) and “Web part” component.

7. Feature.xml

Please remember to change ID, as this is the feature id.

this file let us pack everything in one feature, so when user will active this feature all those artifacts will be available for him. This is really cool thing around SharePoint and I encounter everyone to use it as much as possible.

8. Packing everything – manifest.xml, ddf and makecab

We are almost on the end. Now what we need is to pack this entire stuff into one container (wsp file) and send it to IT operation to be deployed on our farm. To do so, please add two additional files to our solution:

Open “Manifest.xml” file and place inside it this content:

here we are referencing artifacts we created before and in addition we asking SharePoint to add “SafeControl” section to web.config (this section is required to let our web part to work)

Now, please open “makewsp.ddf” file and place inside this content:

this is the list of files with “makecab” should pack into cab file.

If you do so, then we are done!!!, fire makecab with “/f” parameter, provide name for “makewsp.ddf” file and enjoy your package (here is exact command to start when you are located at project folder : makecab /F Deployment/makewsp.ddf /D CabinetNameTemplate=Article02CT.wsp /D DiskDirectory1=wsp) . I hope that this shows you how easy it is to create your custom “article solution”, pack it into wsp and send for the business to start using. In addition, as you can see you can quite easy extend the layout thru building your own bound controls.

In case of questions, problems – please post the question here or email me directly.

Here is a link to entire Visual Studio 2008 solution : ArticleSolution02%5E_20091112.zip

Written by Mariusz Gorzoch

12 November 2009 at 15:06

Posted in Bez kategorii