Jespers Blog

First of all Jesper has a new blog at http://jesperen.wordpress.com.

I am glad to see Jesper writing a blog and it seems that more and more of my collegues are also writing blogs.

The main reason I haven't been writing in a long while, is lack of time and an internal debate on what is proper to write in a blog. Unfortunately that still hasn't been solved, which is very frustrating.

Multi Upload

As most of you are aware of, the media library has changed a lot in 5.3. The change was prompted by the need to store the media files inside the Sitecore database, so that media could be versioned. As a side effect, we were given the chance the change how the user works with the media library.

From the start we wanted the user to work with media items in exactly the same way that they work with items - the user should feel that a media item is "just an item with an embedded file". This would make media item first-class citizens of Sitecore which they really haven't been before.

This strategy has turned to be not-quite-true.

This is especially apparent when you look at the common scenario of uploading 8 images to Sitecore. Our first design required the user to switch from the content editor to the media library, create 8 items and then attach the 8 images to each item. Quite cumbersome.

The next design allowed the user to upload the items directly from the Image Browser dialog. After each upload the Content Editor was shown in a popup dialog box to ensure that the user supplied required information like Alt texts and width and height. However this still required the user to click to the upload button 8 times.

Finally we have surrended, and implemented a new upload dialog that allows the user to upload multiple images in one go. This is still not an ActiveX solution, so we have to use the multiple input field trick, that we have used in previous Sitecore versions.

When the user clicks an item in the Uploaded Media Items pane, the Content Editor is shown in a popup dialog box.

The upload box shows a couple of new features.

1. Uploaded media items either be versioned or not. This controls which template the media item is created from.
2. The Uploaded Files pane shows meta data for each media item- in this case the size of the uploaded file.
3. Uploaded media item are validated -"lighthouse jpg" has two warnings, which is probably that the Width and Height fields are empty.

Media Meta Data and Media Validation are new concepts that the developer can attach to a media type via the web.config. This means that you can implement your own way of supplying meta data to a media item and validate that the fields are correct.

Template Builder

We are gettting a lot of positive feedback on the recent beta release, which is extremely nice. People seem to be happy about the speed of the client and the system in general.

However one particular comment keeps recurring which is that while the Template Editor has been improved, it is still not good enough. This has been so prevaliant, that I decided that we needed to address this issue, so I spent that last couple of days implementing the Template Builder.

The purpose of the Template Builder to speed up template editing by hidding some of the complex settings, like setting field titles in all languages and specifing security. You can still open the Template Editor, which is unchanged, by using the Advanced button in the ribbon.

The metaphor in the Template Builder is creating an SQL table which should be familiar to most developers. That is why the field are shown in a grid style. To add a new section or field, you simply start typing in the last row (and a new row magically appears).

The user can make changes to all sections and fields and these are only saved when the user clicks the Save button. This improves the working speed dramatically.

Some Sitecore veterans will probably get a good laugh out of the Template Builder as it bears striking similarites to template editing in version 2 and 3.

I hope most developers will be happy about the new Template Builder and that we actually try to listen to what you are saying.

Debugging Sheer

There is a very useful way of seeing what is actually sent to the browser in a Sheer event. In the /sitecore/shell/controls/sitecore.js file look for a line like this:

// this.debug();

It is in the parse() function.

If you uncomment this line and refresh the browser (to reload the JavaScript), you will start seeing message boxes for every command that is sent to the browser. (After a while this gets really annoying, so you will comment the line back soon.)

What you see in the box is a single command with named attributes and the value. Usually each request generates a number of commands, so you will get a number of boxes.

The above command registers the key code "c68" which is Ctrl+D with the mesage "item:duplicate".

Image Alt Attributes

The Media Library has received a major overhaul in 5.3. The image files are now stored inside the database - and not in the /Upload folder - which allows real versioning and workflow control over media items.

As part of this and the tools for W3C compliance, we have changed howthe image Alt texts are handled. In the previous 5.x versions the Alt text was fetched from the Alt attribute on the link to the media item, so that you could have different Alt texts depending on where you used the link. If you didn't specify a text in the attribute, the Alt text was blank.

In 5.3 if the Alt attribute is blank, we use the Alt text on the Image item. This allows the user to specify a general text on the image, that can be overridden per link.

Html Validation

In 5.3 we have added some tools to check for compliance with the W3C standards.

The new Html editor (R.A.D. Editor from Telerik) have built-in support for this.

The Content Editor has a button for checking all Html fields in one go (in the Review tab).

and the Debugger has a button for checking the current page.

We hope that these 3 functions will help users and developers make compliant Html.

Sitecore XPath

The Sitecore XPath query language is a custom-implemented subset of XPath. The main difference is that instead of this:

"/item[@key='sitecore']/item[@key='content']/item[@key='home']"

you can write:

"/sitecore/content/home"

which is much easier.

Sitecore XPath can be used from the API using the Database.SelectItems(...) or Database.SelectSingleItem(...) methods. In the Sitecore Client you can use the it in the sources for Lookup, ValueLookup and MultiList fields. e.g.

"query:/sitecore/content/home/*"

which yields the subitems of home.


You can also use Sitecore XPath in the new XPath Builder in the Developer Center of 5.3.

The performance in .NET 2.0 is probably not as good as real XPath (.NET 1.0 and 1.1 is another story), but for some tasks you prefer simplicity over speed - rarely, but it happends.

(Update: I have added a bit more explanation)

The reason for this post is really that we made a small addition to the syntax. You can now quote identifiers with hashs (#). Suppose you have an item with the name "News - Corporate". Before you could not address this item as the dash (-) would be interpreted as an operator and not a part of the name. To solve this you can now write:

"/sitecore/content/Home/#News - Corporate#"

Everything between the hashs is considered a name or an identifier.