benrobb's blog

Just a quick one today:

In a wonderful bit of consistency in naming convensions, the way of getting properties about the current site (SPWeb) is by using the ProjectProperty web control:

<SharePoint:ProjectProperties Property="Title" runat="server"/>

In the case of a Page Layout being used in a Publishing environment, ProjectProperties will give you properties of the SPWeb of the Page not the Page Layout.

I've failed to find a list of available properties (the other obvious one I know is "Description"), and I've also not found a way of adding to the project properties (c.f. custom channel properties in MCMS). If I find any more info about this I'll do another post on this.

Just a quick one today:

In a wonderful bit of consistency in naming convensions, the way of getting properties about the current site (SPWeb) is by using the ProjectProperty web control:

<SharePoint:ProjectProperties Property="Title" runat="server"/>

In the case of a Page Layout being used in a Publishing environment, ProjectProperties will give you properties of the SPWeb of the Page not the Page Layout.

I've failed to find a list of available properties (the other obvious one I know is "Description"), and I've also not found a way of adding to the project properties (c.f. custom channel properties in MCMS). If I find any more info about this I'll do another post on this.

I was creating a master page today which was going to be deployed to a farm with many site collections, and I needed to reference an image which was in the local Style Library directly. An easy task if your site collection is at the root of a web application:

< img src=" / Style%Library/Images/MyImage.jpg" alt="My Image"/>

This works fine until you use that master page on a site collection which isn't at the root. The browser doesn't know or care about site collections, and interprets the src path as being relative to the website. In this case, in a site collection at "/sites/NewSiteCollection" this path should have been:

< img src=" / sites/NewSiteCollection/Style%Library/Images/MyImage.jpg" alt="My Image"/> 

Interestingly, there are no <img> tags in any of the out of the box master pages or page layouts. The answer is to use the same $SPUrl syntax that the <SharePoint:CSSLink> tag in, for example, default.master. The syntax for this is:

<img src="<% $SPUrl:~SiteCollection/Style%Library/Images/MyImage.jpg %>" alt="My Image" runat="server"/>

[It is important to include runat=server, because otherwise the literal text (e.g. <% $SPUrl...) will be sent to the client without any processing by the server.]

Simple really. For future proofing I'm always going to use this syntax in my master pages and page layouts.

PS: Yes. So its been a while since I blogged. I'm still alive, just very busy at work. Rather than try and produce big in-depth blogs, its probably easier to do shorter ones like this.

I was creating a master page today which was going to be deployed to a farm with many site collections, and I needed to reference an image which was in the local Style Library directly. An easy task if your site collection is at the root of a web application:

< img src=" / Style%Library/Images/MyImage.jpg" alt="My Image"/>

This works fine until you use that master page on a site collection which isn't at the root. The browser doesn't know or care about site collections, and interprets the src path as being relative to the website. In this case, in a site collection at "/sites/NewSiteCollection" this path should have been:

< img src=" / sites/NewSiteCollection/Style%Library/Images/MyImage.jpg" alt="My Image"/> 

Interestingly, there are no <img> tags in any of the out of the box master pages or page layouts. The answer is to use the same $SPUrl syntax that the <SharePoint:CSSLink> tag in, for example, default.master. The syntax for this is:

<img src="<% $SPUrl:~SiteCollection/Style%Library/Images/MyImage.jpg %>" alt="My Image" runat="server"/>

[It is important to include runat=server, because otherwise the literal text (e.g. <% $SPUrl...) will be sent to the client without any processing by the server.]

Simple really. For future proofing I'm always going to use this syntax in my master pages and page layouts.

PS: Yes. So its been a while since I blogged. I'm still alive, just very busy at work. Rather than try and produce big in-depth blogs, its probably easier to do shorter ones like this.

So I was playing with some examples of exporting some site columns, wrapping them into features and then installing them on a new box. All straightforward except when it came to publishing webs.

The SPFieldType enum has a number of options, none of which look particularly like "Publishing Image" or "Publishing HTML". When iterating through the available fields in my root web:

foreach (SPField spField in rootWeb.Fields)
{
   string fieldType = spField.Type.ToString("f");
}

I was surprised to find that these fields were returning "Invalid" as their field type.

Only by chance, some time later, did I stumble upon the alternative:

foreach (SPField spField in rootWeb.Fields)
{
   string fieldType = spField.TypeAsString;
}

which gave "Image" and "HTML" as the field types.

Confused? I was.

EDIT: A bit of reflection shed some light on this. Not a lot, but a bit. The field "Type" has the following code:

public SPFieldType Type
{
   get
   {
      return SPField.GetFieldType(this.TypeAsString);
   }
   set
   { … }
}

GetFieldType attempts to set the string passed  to it to the enum, and returns SPFieldType.Invalid if it can't – e.g. when its a field type which is only exposed by MOSS.

So I was playing with some examples of exporting some site columns, wrapping them into features and then installing them on a new box. All straightforward except when it came to publishing webs.

The SPFieldType enum has a number of options, none of which look particularly like "Publishing Image" or "Publishing HTML". When iterating through the available fields in my root web:

foreach (SPField spField in rootWeb.Fields)
{
   string fieldType = spField.Type.ToString("f");
}

I was surprised to find that these fields were returning "Invalid" as their field type.

Only by chance, some time later, did I stumble upon the alternative:

foreach (SPField spField in rootWeb.Fields)
{
   string fieldType = spField.TypeAsString;
}

which gave "Image" and "HTML" as the field types.

Confused? I was.

EDIT: A bit of reflection shed some light on this. Not a lot, but a bit. The field "Type" has the following code:

public SPFieldType Type
{
   get
   {
      return SPField.GetFieldType(this.TypeAsString);
   }
   set
   { … }
}

GetFieldType attempts to set the string passed  to it to the enum, and returns SPFieldType.Invalid if it can't – e.g. when its a field type which is only exposed by MOSS.

I'll be there next week – looking forward to catching up with some of the SP community there. Anyone else going? 

I'll be there next week – looking forward to catching up with some of the SP community there. Anyone else going? 

Mei Ling has written a great blog about getting Commerce Server 2007 working with MOSS. This has been on my list of things to look at for a while, and something that has been bugging me since I first looked at MOSS way back at PDC last year.

There does still seem to be a huge disconnect between the MOSS team and the CS team. This is a shame because they had a great opportunity to do some really good work here.

Looking at what Commerce Server gives you there seems to be a massive overlap of functionality, and there isn't much in the way of guidance about which to use. If we break down the functional components of CS, you'll see what I mean.

Membership and Roles

Out of the box providers hooked up to CS. Using Forms Authentication, you could easily reuse the same in a MOSS environment.

Catalog Management

Commerce Server gives you rich catalog management functionality. Here, you could go down one of a number of paths. If all you needed was a catalog management function, you could easily define a few custom Content Types and some lists and you'd have the same functionality. However, you woudln't have the integration with the basket and order management functions, so its probably best to leave it in the CS database. So here you have a choice, either:

a) Use the BDC to consume your CS catalog (I'm sure there will be community inspired bits to give you a default CS BDC definition).

b) Write your own CS web parts to use directly within MOSS (and why haven't MS written these, I ask…)

I would say that it will be a combination of these last two methods.

Checkout Processing and Order management

You may well ask why they didn't decide to rip out the (difficult to debug) pipeline framework and replace it wholesale with Windows Workflow. I for one would have cheered. But they didn't. Personally, I'm going to be ignoring the checkout processing and order management in my solutions and going with InfoPath forms and workflow to put stuff in the correct databases, and send messages through BizTalk to actually take the money and send orders to the fulfillment houses.

eMarketing

One of CS's other big functional areas is in eMarketing, and again we see more than one way of doing stuff. Do you use the CS targetting system or MOSS audiences? Not sure. But I know that it will confuse my users if they have to use two different systems to target their users. I'm probably falling on the side of audience targetting through MOSS, simply because our clients will want to target both products and content to the same audience groups.

Discounting System.

This is one of the stronger points of CS, and I can't see anything obvious in MOSS to replicate this functionality.

Reporting and Analytics

CS uses SQL 2005 Reporting and Analytics, so these reports can be consumed into a Report Center within an MOSS Intranet.

So in conclusion, the CS team need to ask themselves where their value add is in the new world of MOSS. Apart from the discounting system, and the shopping basket functionality, its difficult to see what CS offers that a small amount of custom dev work on MOSS wouldn't give you. It will be interesting to see what CS gives us in the next version…

Mei Ling has written a great blog about getting Commerce Server 2007 working with MOSS. This has been on my list of things to look at for a while, and something that has been bugging me since I first looked at MOSS way back at PDC last year.

There does still seem to be a huge disconnect between the MOSS team and the CS team. This is a shame because they had a great opportunity to do some really good work here.

Looking at what Commerce Server gives you there seems to be a massive overlap of functionality, and there isn't much in the way of guidance about which to use. If we break down the functional components of CS, you'll see what I mean.

Membership and Roles

Out of the box providers hooked up to CS. Using Forms Authentication, you could easily reuse the same in a MOSS environment.

Catalog Management

Commerce Server gives you rich catalog management functionality. Here, you could go down one of a number of paths. If all you needed was a catalog management function, you could easily define a few custom Content Types and some lists and you'd have the same functionality. However, you woudln't have the integration with the basket and order management functions, so its probably best to leave it in the CS database. So here you have a choice, either:

a) Use the BDC to consume your CS catalog (I'm sure there will be community inspired bits to give you a default CS BDC definition).

b) Write your own CS web parts to use directly within MOSS (and why haven't MS written these, I ask…)

I would say that it will be a combination of these last two methods.

Checkout Processing and Order management

You may well ask why they didn't decide to rip out the (difficult to debug) pipeline framework and replace it wholesale with Windows Workflow. I for one would have cheered. But they didn't. Personally, I'm going to be ignoring the checkout processing and order management in my solutions and going with InfoPath forms and workflow to put stuff in the correct databases, and send messages through BizTalk to actually take the money and send orders to the fulfillment houses.

eMarketing

One of CS's other big functional areas is in eMarketing, and again we see more than one way of doing stuff. Do you use the CS targetting system or MOSS audiences? Not sure. But I know that it will confuse my users if they have to use two different systems to target their users. I'm probably falling on the side of audience targetting through MOSS, simply because our clients will want to target both products and content to the same audience groups.

Discounting System.

This is one of the stronger points of CS, and I can't see anything obvious in MOSS to replicate this functionality.

Reporting and Analytics

CS uses SQL 2005 Reporting and Analytics, so these reports can be consumed into a Report Center within an MOSS Intranet.

So in conclusion, the CS team need to ask themselves where their value add is in the new world of MOSS. Apart from the discounting system, and the shopping basket functionality, its difficult to see what CS offers that a small amount of custom dev work on MOSS wouldn't give you. It will be interesting to see what CS gives us in the next version…