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.

JSON

I guess not a lot of you need to know this, but anyway...

We have changed the protocol that Sheer UI uses to communicate from an XML based protocol to JSON.

It has saved us a bunch of JavaScript code and made each request about 15ms faster which is very nice. JSON is defintely the format to use when using JavaScript.

IgnoreUrlExtensions

I have added a new setting in the web.config - IgnoreUrlExtensions - which allows certain file types to bypass the layout engine. For instance web services do not need a layout - in fact the engine messes a web service up.

Extensions are specified by extension excluding the dot and are seperated by a pipe (|).

E.g.
<setting name="IgnoreUrlExtensions" value="asmx|png|gif|jpg" />

The settings is handled in the HttpRequest pipeline after the site (database, domain etc.) has been setup - this means that you can still access the correct database, even though the filetype is ignored. This is a major difference from IgnoreUrlPrefix.

Wallpaper

I just implemented a couple of missing features in the wallpaper dialog box.

Previously you could only specify the wallpaper image, but now you can also specify a position and a background color.


This may seem like small things, but they are very important for most users. It makes the users feel in control of the system and not the other way around.

Keyboard Shortcuts

We are optimizing the Content Editor to be less mouse-centric. I expect that this will make a lot of developers and power-users very happy (including myself).

The new Ribbon supports keyboard shortcuts. The ribbon button templates Large Button, Small Button etc. all have a field called KeyCode which triggers the click event on that button.

A keycode is a standard Sitecore keycode, e.g. "c68" for Ctrl+D. The Keyboard Map application in Sitecore can be used to obtain the keycodes. There are of course some keys that cannot be override as IE uses these.


The current bindings are:
Ctrl+S: Save
Ctrl+D: Duplicate
F2: Rename
Ctrl+Home: Goto to Home node
Shift+Ctrl-Alt-Up: Sort Up
Shift+Ctrl-Alt-Down: Sort Down
Shift+Ctrl-Left: Back
Shift+Ctrl-Right: Forward
Ctrl+F2: Expose (window manager)
Ctrl+Windows: Start Bar
F9: Publish
Ctrl+F9: Publish Item

Hopefully we will have more as time comes.

We have started using the <a> for clickable objects in the Content Editor, which gives us a number of benefits. One of them is that tabbing on works, so you should be able to reach any part of the Content Editor UI using Tab, which is very nice.

The content treeview also supports navigation via the keyboard. The means that you can use the arrow keys to change focus and expand/collapse branches.

SQL Express and Cassini

We have done a couple of conversions that have eased the development some.

Last thursday Ole moved the databases to SQL Express (with a heavy bribe from me). While Firebird is an excellent database, it's strength is also it's weakness. As it runs InProc with the ASP.NET process, it has to rebuild its cache whenever we rebuild the VS project. This takes just a little time - not something you would normally notice - but as we rebuild about 100 times a day, it is something we can feel. And I like the flexibility of being able to choose between SQL Server, SQL Express and Firebird.

Today Runi showed me how to get Sitecore running on Cassini - the web server that comes with Visual Studio 2005. It was just really an issue of getting used to it - there were no problems at all. The big advantage of using Cassini is that I do not have to reconfigure the IIS every time I change project, which happens a lot when we build patches. I have been using the Sitecore IE Toolbar for a long time, but I hope that time is over now.

Browser Display Mode

In order to maximize the amount of screen real-estate for the user we have added a number of display mode options to the login screen.


The Normal options show the browser with toolbars - no surprises here.

The "Without Toolbars" omits the toolbars.


The "Fullscreen" option maximize the browser and does not show any toolbars - even without the otherwise annoying fly-out toolbar (pretty sure this is not going in IE7 as it is a great way of doing phising attacks).

Client Roles

Sitecore 5.3 introduces seven new security roles that determines how the Sitecore Client appears. While we have previously used the roles Editor, Webmaster and Developer, we realized that we needed something a little more fine-grained. Also the Editor, Webmaster and Developer was used to specify access to content items which meant a mix-up between Client capabilities and security rights to content items.

The new roles makes this much cleaner and easier to setup. And without further ado: the seven new roles are:

1. Sitecore Client Authoring
2. Sitecore Client Configuring
3. Sitecore Client Translating
4. Sitecore Client Publishing
5. Sitecore Client Securing
6. Sitecore Client Maintaining
7. Sitecore Client Developing

The name have been chosen very carefully. We needed to indicate that these roles are used in the client and not with content items, and we also needed to give them a sort of capability ring, so that you could have an Editor with Authoring and Publishing capabilities.

The customer can piece together their security roles from our standard Client roles. A typical Editor would have Authoring and Publishing while a developer would have Authoring, Configuring, Maintaining and Developing. It is important to notice that only the Security Officer should have the Securing role. Kerry has a Word document with a matrix that shows exactly which features each role controls.

There were some talks about other roles, e.g Previewing and Archiving, but we decided on simplicity and seven roles seems like an upper-limit on that.

I just finished setting up the client with these roles, and I am fairly impressed with it. The new UI really makes it easy to see what each role is about, and the combination of roles seems very powerful and easy to use.

This has always been an area where Sitecore has been lacking and it nice to see that it is finally taking shape.

Sorting

On the major wishes on my list for 5.3 was sorting. The wish came in two flavors: the end-user should be able to drag/drop an item to change its sorting position and an item should be able to determine how it's children are sorted.

The good news is that both features have been implemented. The bad is news is... well there isn't any bad news (which is also good news).

To drag/drop an item to a new sorting position, the user should hold down the Alt key while dragging. There is no UI feedback for this unfortunately.

I have added a new field on the standard template called Subitems Sorting. This is a lookup box to /sitecore/system/Settings/Subitems Sorting. This item holds possible sortings, which is really just pointer to a .NET class, e.g. "Sitecore.Data.Comparers.DefaultSorting,Sitecore.Kernel".

This class must implement the IComparer interface, and we have provided a base class "Sitecore.Data.Compares.Comparer", if you want to use it. This architecture makes it possible to implement custom sortings besides the 5 basic sortings Sitecore provide: Default, DisplayName, Logical, Reverse and Updated.

When a user clicks the Subitems Sorting button in the Ribbon, she sees the following box:

There is a nice preview of how the sorting is going to look after it has been applied.

The ribbon also have a Reset Sorting options, that remove the explicit sort-order field on each subitem. This ensures that the sort-order field does not overrule the sorting set on the parent item.

Security Presets

5.3 introduces a new UI tool called Security Presets. It allows the user to set predefined security settings in a single click.


Presets are defined in the system section using a template that has the following fields:

1. Users or Roles
2. Domain
3. Allowed
4. Denied
5. Inherited
6. Inherits

We will probably make some UI that makes it easy to create these presets, but for now it is not on the roadmap.

The Allowed, Denied and Inherited fields is a combination of rights on the form "rwcnda" for Read, Write, Create, reName, Delete and Administer.

I hope this little piece of UI will make the life of security administrators much easier.