This post continues the series about the new field editing infrastructure introduced in Sitecore 6: I’ve talked about the renderField pipeline, and how you should be using renderField from .NET. Today is the example day.

Let’s start with links. You can put sc:Link control directly on the aspx page:

<sc:Link Field="Link" runat="server" />

This is a minimum set of parameters – you need to specify the field name at least. The control will use context item to get the field value. If you need any other item, you can use Datasource property in a declarative manner:

<sc:Link Field="Link" DataSource="/sitecore/content/home" runat="server" />

To change the text of the link, you can use the Text property, but Link control is also able to render embedded content:

<sc:Link Field="Link" DataSource="/sitecore/content/home" runat="server">
  Link text
</sc:Link>

And of course  it can render child controls:

<sc:Link Field="Link" DataSource="/sitecore/content/home" runat="server">
  <sc:Image MaxWidth="200" MaxHeight="200" Field="Image" runat="server" />
</sc:Link>

The same using C#:

var link = new Link {Field = "Link", Item = Sitecore.Context.Database.GetItem(someId)};
var image = new Sitecore.Web.UI.WebControls.Image {Field = "Image", MaxWidth = 200, MaxHeight = 200};
link.Controls.Add(image);

MainPanel.Controls.Add(link);

Notice that controls also have the Item property. The difference between Item and DataSource is that one is designed for API use and accepts Item class, and the other is designed for declarative use and accepts strings.

All of the examples above support Page Editor, including the image nested inside link.

I’m starting on twitter at http://twitter.com/a_rusakov – I’ll experiment with format and content, but the primary focus is still Sitecore and everything related to it. It will not interfere with this blog, but hopefully supplement it in a useful way.

Twitter is a micro blogging platform, most known for limiting the length of one message (“update” or “tweet”) to 140 symbols, which dictates its own format. However twitter has also grown to a social platform with its unique flavor, supporting public conversations.

If you don’t want to use twitter but would still like to subscribe to (“follow”) my updates, you can use RSS.

Sitecore 6 Update 6 is released, and the only fix is the support for uploading files with Flash 10 installed.

Download.

A little bit of insight: you probably heard that Adobe has introduced a new “security” rule in Flash 10 that says that Open file dialog can only be shown in a response to user interaction in flash. The rule effectively broke all javascript/flash uploaders, including the one we’ve used. The simplest hack around that rule is to overlay your HTML UI with a transparent flash object, and the updated flash-10-supporting libraries allow this overlay to be created using javascript.

As a positive side effect of having to redo the upload UI, uploading from media folder should open somewhat faster now. I’ve also switched our underlying library from SWFupload to YUIupload, which seemed like a better supported project.

Today I’ve made google chrome a default browser on my laptop and work PC. I’ve noticed that I was spending more and more time in chrome for casual browsing, and when someone IMs me a link, waiting for Firefox to load is just a waste of time. Speed and sumplicity  finally won me over firefox addins.

From now on, it’s IE for Sitecore, Firefox for firebug and Chrome for everything else.

We’ve released a major overhaul of the poll module. Improvements:

• Sitecore 6 support, including using Page Editor to modify existing polls
• New polls can be added using Sitecore 6 Page Editor
• Staging support
• AJAX voting
• Fully automated installation
• Simplified architecture: the module no longer uses an additional database, which also allowed us to completely remove the settings application
• Better looks
• Easier customization: we’re using more xhtml and css, and less tables. Instead of c# webcontrol code, we’re using an ascx sublayout that is much easier to tweak without having to compile the code
• Refactored code and reviewed design

The Poll module is part of Sitecore shared source program, and it stays that way. However we’ve dedicated our QA and development to reshape the module and release a clean and well tested Sitecore 6 version. We used the same open svn/trac server for entire development process, and you can see change history.

From now on, the module continues its life as a shared source component, meaning that you can (and very welcome to) contribute. I was doing product management type of work on the project, while Michael Baranov gets all the praise for beautifying the code.

My favorite feature is the ability to add new polls directly through the Sitecore 6 Page Editor.

1. Click “Insert Poll”

2. Setup poll using a pop-up wizard

3. Select a placeholder

4. Done.

You can also edit existing polls from the Page Editor:

Content layout is changed, so that you’re no longer required to store all polls in a single location. This setup beautifully supports multisite solutions.

And bugs, lots of bugs were fixed:

Hope you like the update. Downloads, documentation and source code are all available at http://trac.sitecore.net/Poll.

I’m attending my first PDC this year, and I’m definitely up for a few drinks – let me know if you’re around. Email’s alexey at this domain.

Not quite sure what to expect from the conference –  looking forward to C# 4.0, User Experience and Silverlight talks.

Changes:

Issues fixed:

1. Fixed: Cross site links were not working as expected. Such links now include the hostname of the target site and are generated relative to the start item of the target site. This functionality can be disabled by setting Rendering.SiteResolving to “false” in the web.config file.

2. Fixed: a selected Publishing Target of an item was not taken into account when performing Publish operations.

3. Fixed: The performance of item creation has been significantly improved.

New features:

1. The FastQueryDescendantsDisabled setting has been added to the web.config file. It may be set to true to disable the ability to use fast query to select items through Ancestors/Descendants axes. This will give a small performance increase of item creation/moving/deletion.

 

Download.

Adobe released Flash player version 10 that breaks uploading in Sitecore.

We’re working on a solution,  do not upgrade to Flash 10 if you can. Another option is to set Upload.Classic = “true” option in web.config – this will replace Sitecore 6 upload with the one used in Sitecore 5, which doesn’t rely on flash.

One of the popular questions about Sitecore is how to get sublayout parameters. Sitecore 5 way of doing that involves advanced API – parsing layout definition for the current item, finding the rendering item, etc.

Sitecore 6 makes this simple enough to remember – the parameter string is stored as a “sc_parameters” attribute of the sublayout.

string rawParameters = Attributes[“sc_parameters”];
NameValueCollection parameters = Sitecore.Web.WebUtil.ParseUrlParameters(rawParameters);

Today I’ll go with the example suggested by Lars. Suppose we’re implementing a new money field type to store both the numeric amount and the currency (229 US Dollars). Both bits of information are stored in a single field using XML, which is a typical approach for Sitecore.

I’ll skip the whole implementing a new field type part (no need to repeat SDN); lets say that the Sitecore Client part is already implemented, and editors are able to use the Content Editor to change field value.

One problem remains – how to output money values on the website? The field contains XML, so we can’t just do sc:fld(‘money’, .). Different currencies have different signs which can go before or after the amount, which makes non-trivial rendering logic. The typical Sitecore 5 solution would be to implement a new XSL extension method and/or .NET web control.

In Sitecore 6, however, you can use the renderField pipeline to make existing rendering methods properly render custom field types.

Once again, this is a clean renderField pipeline:

<renderField>
  <processor type="Sitecore.Pipelines.RenderField.GetFieldValue, Sitecore.Kernel"/>
  <processor type="Sitecore.Pipelines.RenderField.ExpandLinks, Sitecore.Kernel"/>
  <processor type="Sitecore.Pipelines.RenderField.GetImageFieldValue, Sitecore.Kernel"/>
  <processor type="Sitecore.Pipelines.RenderField.GetLinkFieldValue, Sitecore.Kernel"/>
  <processor type="Sitecore.Pipelines.RenderField.GetInternalLinkFieldValue, Sitecore.Kernel"/>
  <processor type="Sitecore.Pipelines.RenderField.GetMemoFieldValue, Sitecore.Kernel"/>
  <processor type="Sitecore.Pipelines.RenderField.GetDateFieldValue, Sitecore.Kernel"/>
  <processor type="Sitecore.Pipelines.RenderField.AddBeforeAndAfterValues, Sitecore.Kernel"/>
  <processor type="Sitecore.Pipelines.RenderField.RenderWebEditing, Sitecore.Kernel"/>
</renderField>

Most processors are responsible for rendering specific field types, plus there are some additional processors supporting Sitecore architecture.

Following the naming convention, we’ll create a new GetMoneyFieldValue processor and place it after all Get* processors, but before the AddBeforeAndAfterValues:

The processor responsibility is to render HTML. I’m assuming that money field contains the following XML: <money currency=”USD” amount=”229.99” />

public class GetMoneyFieldValue {
  public void Process(RenderFieldArgs args) {
    if (args.FieldTypeKey != "money") {
      return;
    }

    var doc = new XmlDocument();
    doc.LoadXml(args.FieldValue);

    string currency = doc.DocumentElement.GetAttribute("currency");
    string amount = doc.DocumentElement.GetAttribute("amount");

    string result = string.Empty;

    if (currency == "USD") {
      result = "$" + amount;
    }
    else if (currency == "DKK") {
      result = amount + " kr.";
    }

    args.Result.FirstPart = result;
  }
}

First, and most importantly, the processor has to check the type of the field being rendered. It’s only supposed to render money fields and ignore everything else. Then we retrieve the field value – notice the FieldValue property. The value is parsed, and depending on the currency we nicely render the monetary amount of either American dollars or Danish kroner. The result is stored in args.Result.FirstPart - money field is not supposed to be able to wrap other values, so nevermind the LastPart.

Why Bother?

Implementing the above processor gives website developers the ability to use standard Sitecore field rendering methods to properly render money fields. Developers can do sc:field(‘money’, .) or use the FieldRenderer class and never have a second thought.