Sitecore CMS and everything related RSS 2.0
 Thursday, October 23, 2008

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.

Thursday, October 23, 2008 3:54:55 PM (FLE Standard Time, UTC+02:00)  #    Comments [3]
Personal | User Experience
 Wednesday, October 22, 2008

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”

image

2. Setup poll using a pop-up wizard
image

3. Select a placeholder

image

4. Done.

You can also edit existing polls from the Page Editor:

image

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.

image

And bugs, lots of bugs were fixed:

image

 

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

Wednesday, October 22, 2008 5:13:12 PM (FLE Standard Time, UTC+02:00)  #    Comments [2]
Sitecore | Open Source
 Tuesday, October 21, 2008

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.

Tuesday, October 21, 2008 10:00:30 AM (FLE Standard Time, UTC+02:00)  #    Comments [0]
Personal
 Friday, October 17, 2008

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.

Friday, October 17, 2008 10:12:02 AM (FLE Standard Time, UTC+02:00)  #    Comments [0]
Sitecore
 Thursday, October 16, 2008

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.

Thursday, October 16, 2008 1:05:11 PM (FLE Standard Time, UTC+02:00)  #    Comments [0]
Sitecore
 Tuesday, October 14, 2008
Getting sublayout parameters in Sitecore 5

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);

Tuesday, October 14, 2008 1:07:29 PM (FLE Standard Time, UTC+02:00)  #    Comments [5]
Sitecore | Crestone
 Thursday, October 09, 2008

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:

  <processor type="Sitecore.Pipelines.RenderField.GetDateFieldValue, Sitecore.Kernel"/>
  <processor type="Money.GetMoneyFieldValue, Money" />
  <processor type="Sitecore.Pipelines.RenderField.AddBeforeAndAfterValues, Sitecore.Kernel"/>

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.

Thursday, October 09, 2008 10:57:00 PM (FLE Standard Time, UTC+02:00)  #    Comments [5]
Sitecore | Crestone
 Thursday, September 18, 2008

FieldRenderer control being added to the page using the Sitecore Page DesignerIn the last post I’ve mentioned the new ways of rendering fields using .NET code using web controls. Today I’ll focus on them more closely.

The purpose for introducing these controls is two-fold: to allow .NET developers enjoy the same simplicity of rendering various Sitecore field types available in the XSL world, and to support the Page Editor.

The most notable addition is the Sitecore.Web.UI.WebControls.FieldRenderer web control. This is basically a renderField pipeline wrapped in a web control form. You need to at least specify the field name and the control will do the rest. Optional parameters include the context item, html to render before and after the field and additional parameters. Another useful thing about FieldRenderer is that it’s also registered as a web control rendering in Sitecore, which allows power users to output different field types right from the Page Designer.

The same FieldRenderer class also contains a static shortcut render method: Render(Item item, string fieldName [, string parameters]): string. This is the easiest way to render a field – use it when having web control is not desirable, and you’d rather just get result as a string.

Along with FieldRenderer we’ve also introduced a number of web controls tailored to render specific field types:

Sitecore.Web.UI.WebControls.Date
Sitecore.Web.UI.WebControls.Image
Sitecore.Web.UI.WebControls.Link
Sitecore.Web.UI.WebControls.Text

The benefit of these controls is that they provide strongly typed properties, similar to the ones available in their XSL counterparts. For example the Image web control has Alt, MaxHeight and MaxWidth properties. If you want to use these controls but still just get a string as a result, use the Sitecore.Web.HtmlUtil.RenderControl(Control):string convenience method.

The most important thing to remember is that if you’re using .NET code to output field values, you have to use one of the above ways to support the Page Editor , because something like Response.Write(item[“FieldName”]) just won’t do it.

Thursday, September 18, 2008 6:45:29 AM (FLE Standard Time, UTC+02:00)  #    Comments [2]
Sitecore | Crestone
 Monday, September 15, 2008

Sitecore’s renderField pipeline is a supporting pillar for the Page Editor. The pipeline ties together XSL and .NET field rendering code into one and provides a single place to affect how each field type (rich text, image, link) is rendered on the website.

It doesn’t matter if the field is being output using XSL extension methods (sc:field, sc:image), XSL controls (<sc:text />, <sc:image />) or the new family of .NET web controls (Sitecore.Web.UI.WebControls.FieldRenderer, Date, Image, etc) – the renderField pipeline is always the one that provides the actual output.

How does this support the Page Editor? Whenever a page is being run in the page editor mode, the renderField pipeline knows that and renders additional html/javascript around each field.

How is the pipeline useful to you? The ability to hook into a field rendering process and modify the look of any field on a website is a powerful feature. For example you could completely change the way some or all images are rendered, or merely postprocess the rich text fields, like in the following example. This pipeline would also interest implementers of new field types, because it’s now possible to teach standard output methods to render third party fields types.

The code below checks all links rendered as a part of the rich text field and adds the “external” CSS class to all external links. This can be useful to style external links differently, like using different colors or adding an icon next to them.

public class MarkExternalLinks {
  public void Process(RenderFieldArgs args) {
    if (args.FieldTypeKey != "html" && args.FieldTypeKey != "rich text") {
      return;
    }

    if (!args.Result.ToString().ToLower().Contains("<a")) {
      return;
    }

    var firstPart = new HtmlDocument();
    firstPart.LoadHtml(args.Result.FirstPart);
    MarkLinks(firstPart);
    args.Result.FirstPart = firstPart.DocumentNode.OuterHtml;
  }

  private void MarkLinks(HtmlDocument document) {
    var nodes = document.DocumentNode.SelectNodes("//a");
    if (nodes == null || nodes.Count == 0) {
      return;
    }

    foreach (var node in nodes) {
      if (node.GetAttributeValue("href", string.Empty).Contains("http")) {
        var className = node.GetAttributeValue("class", string.Empty);
        if (className.Length > 0) {
          className += " ";
        }

        className += "external";
        node.SetAttributeValue("class", className);
      }
    }
  }
}

OK, what happens here? First, the check for the field type is performed. This processor is only designed to alter the output of html and rich text fields. If the field contains any links, output is being processed using the Html Agility Pack. The rendered field is stored in args.Result. The reason for having both FirstPart and LastPart is to render fields that can have other content embedded in them, such as general link; rich text fields only have the FirstPart.

Now the processor needs to be placed in web.config. I’m putting it just before the RenderWebEditing processor, so that it doesn’t affect the additional links rendered to support Page Editor. It’s also important that it comes after the GetLinkFieldValue processor:

<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="Pipelines.MarkExternalLinks, Pipelines" />
  <processor type="Sitecore.Pipelines.RenderField.RenderWebEditing, Sitecore.Kernel"/>
</renderField>

Once again, here are the different ways of properly rendering a field:

  1. sc:field XSL extension method, and the family of field type specific methods such as the sc:image, sc:link, sc:date and so on
  2. XSL controls: <sc:text />, <sc:image />, <sc:date /> and so on
  3. The Sitecore.Web.UI.WebControls.FieldRenderer web control, and a family of field type specific web controls, such as Sitecore.Web.UI.WebControls.Image, Date, etc [new]
  4. The Sitecore.Web.UI.WebControls.FieldRenderer.Render() shortcut method. Use it when having the web control is not desirable, and you’d rather just have a string. [new]

It’s important to understand when the renderField pipeline is not used:

  1. sc:fld XSL extension method returns raw field value, bypassing the pipeline.
  2. Field values read using the Sitecore API (item[“FieldName”] or item.Fields[“FieldName”].Value) also return raw values.
  3. Any static html included in the aspx or ascs files is also not processed.

Consequently, these are also the ways of supporting the new Page Editor in Sitecore 6: as long as you output the field using any of the options from the first list so that the renderField is used, you’re automatically getting the full Page Editor support.

In the next post I’ll focus on the new FieldRenderer web control and the family of field controls, added to make rendering fields in .NET to be as easy as using XSL controls.

Monday, September 15, 2008 6:33:45 AM (FLE Standard Time, UTC+02:00)  #    Comments [1]
Sitecore | Crestone
 Wednesday, September 03, 2008

I’m on vacation in Copenhagen, on 7-10th of September (i.e. next week).

I’ll be checking email from time to time: “alexey at this domain dotcom”.

Wednesday, September 03, 2008 7:11:26 PM (FLE Standard Time, UTC+02:00)  #    Comments [1]
Personal
Archive
<October 2008>
SunMonTueWedThuFriSat
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678
Blogroll
 Alex de Groot
Few words about SiteCore from Holland
 Alexander Shyba
Sitecore Support
 Anders Dreyer
Anders Dreyer on Sitecore Development
 Jakob Christensen
Sitecore Core Development
 Lars Fløe Nielsen
Lars's ramblings about development and business processes
 Ole Thrane
Sitecore API
 Runi Thomsen
Runi Thomsen Sitecore Toughts
 The Sitecore Experience
The Sitecore Experience
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2010
Alexey Rusakov
Sign In
Statistics
Total Posts: 211
This Year: 0
This Month: 0
This Week: 0
Comments: 0
Themes
Pick a theme:
All Content © 2010, Alexey Rusakov
DasBlog theme 'Business' created by Christoph De Baene (delarou)