DotLucene is the engine behind search in Sitecore client. Sitecore itself provides most common patterns of advanced search, allowing to specify ‘created/updated’ date interval, or filter by author.

Here’s how search query looks like when searching for items authored by ‘Admin’ user: author:"sitecore\Admin".
In lucene terms it says to look for documents containing ‘sitecore\Admin’ in ‘author’ field. Don’t confuse lucene’s fields with those of Sitecore, though. To see which fields are there for you to search by (and to add own ones, if you fancy) refer to ‘system’ index declaration in web.config:

<index id="system" singleInstance="true" type="Sitecore.Data.Indexing.Index, Sitecore.Kernel">
  <param desc="name">$(id)</param>
  <fields hint="raw:AddField">
    <field target="created">__created</field>
    <field target="updated">__updated</field>
    <field target="author">__updated by</field>
    <field target="published">__published</field>
    <field target="name">@name</field>
    <field storage="unstored">@name</field>
    <field target="template">@tid</field>
    <field target="id" storage="unstored">@id</field>
    <type storage="unstored">memo</type>
    <type storage="unstored">text</type>
    <type storage="unstored" stripTags="true">html</type>
    <type storage="unstored" stripTags="true">rich text</type>
  </fields>
</index>

And finally, refer to DotLucene Query Syntax for more options, including wildcard and ‘fuzzy’ searches. And since Sitecore 5.3 uses asynchronous search index updates, there’s much less incentive to turn the indexing off.

Ranting about new multiple template inheritance capabilities and its virtues made me think what’s missing: you still cannot extend the template without manually modifying the template itself.

Specific scenario bugging me is extending Sitecore templates, like ‘standard template’, fields, etc. Long story short, I’ve hacked together a quick prototype to share the idea.

The solution adds ‘/sitecore/system/template extenders’ folder, a place to add template extender items. Each extender can extend a list defined templates with  another list of mix-in templates. ‘Extending’ a template basically means making sure that it has mixed-in template as one of the base templates.

 
So from the technical point of view the prototype hooks into the initialize pipeline, and registers all extenders found in /sitecore/system/template extenders each time Sitecore starts up. Initialize pipeline was just the quickest way to hook somewhere, good enough for prototype.

Unlike modifying base templates manually, extending templates in this manner can be done automatically via the package install. It is also more future proof: if the standard template gets modified later, extenders make sure to add base template again, so you can rely on the additional fields being there.

The package requires old packager (developer tools -> packager) to install, and in beta 060705 it looks like you have to fix ‘package folder’ setting in web.config.

Package also installs a sample: two dummy templates (‘A’ and ‘B’) and an extender to add them to standard template. If everything’s alright, you will see two more fields on all items. If not – oh well, this should have been clean throw-away instance.

Package: templateextender_prototype_oldpackager.zip (21.08 KB)
Sources: TemplateExtender_prototype_src.zip (11.81 KB)

Next 5.3 (almost) feature I’m putting my eye on is multiple template inheritance. It looks like a small UI fix, leading to very cool aspect-like stuff.

Notice how ‘base template’ field of every template allows adding multiple templates. Inheriting from more than one template means inheriting union of their fields, simply enough. Sitecore is also first to use the feature:  instead of containing all the sections directly, standard template now inherits from multiple base templates (all defined at /sitecore/templates/system/templates/sections), each containing one particular section.


That’s probably the only example needed to get excited. From solution perspective, it is really easy to create own aggregations, design ‘aspects’ and mix them as appropriate to create concrete templates. It can be sets of common content fields, meta-data or smaller things like image links. If some of the solution item kinds are designed to have graphical links, you can group ‘image’, ‘link’ and ‘text’ fields together and mix it in as base template when needed.

For module vendors it means that there’s no need to feel guilty about extending standard template any longer. It is often really tempting to have your module add new fields to some of the items. RSS Module, for instance, can benefit from having fields controlling feed generation for content items.  5.1-compatible version has ‘Rss Settings Base’ template and instructs user to inherit their template from it. This obviously gets a little more complicated when there’s a lot of existing inheritance in solution. In 5.3 it is possible to either mix base rss template into default template to add rss-specific fields to all items, or decide which of your templates should have that section and add it individually.

And no need to worry about accidentally mixing the same fields twice – this multiple inheritance is a safe one.

As a follow up to the previous post, here’s very subjective comparison of storage engine performance in 5.3.

Microsoft SQL Express. Clear winner. Fastest all around file-based storage option, while still being free. The only downside is that it requires a separate install.

SQLite. Runner-up. While almost matching ‘read’ speeds of SQL express in pure API tests, Sitecore client feels less responsive. Significantly slower on writes, which is most noticeable during the publishing process. Faster than firebird on the same ‘client responsiveness’ scale.

Doesn’t require separate installation, meaning that Sitecore Installer is all you need to get up and running. Due to nature of SQLite, performance might degrade when having large number of concurrent editors.

Firebird. The only file based storage previously existed in 5.x, the slowest choice for 5.3.

Sitecore 5.3 beta1 (or beta 060705 to be precise) is live on SDN5 and the word is out. Everyone reading the Sitecore blogs must have seen the really cool, sheer and 2007-ready Content Editor screenshots. True, it is an impressive stuff, but there must be more to new release than just rehauled Content Editor. I’ve been working with production builds lately and haven’t really had a chance to dive into 5.3. So I’m going to change that and blog at the same time.

After downloading your hot copy, there are things you notice before ever having a chance to play with Content Editor:

Running the .exe file gets you to new installation wizard. After providing a valid Sitecore license (old 5.x licenses work fine) you can pick database engine, installation folder and create new IIS site. Basically it does everything needed to get Sitecore instance up and running, asking minimum amount of questions.


Database selection screen unveils yet another change: new storage engine options. Sitecore 5.3 adds Microsoft SQL Server Express and SQLite support. Both are free file-based storages and last time I saw performance test results, they run faster than Firebird.

Another bit is that SQLite can successfully compete with SQL Express on read operations, which is what serving content is mostly about, while being slower on writes. I’ll check on test results to get back with some more details.

Overall, new installation wizard coupled with fast file-based storage options make deployment a lot easier. I've never used automatic installs previously, but the new one is a nice thing to have.


To wrap off the post, here are 5.3 recourses available:

SDN5:

• Download
• Release notes
• Installation guide

Blogs covering 5.3:

• Jakob Christensen
• Lars Fløe Nielsen
• Alex de Groot
• Peter Johansson

Make sure you have webresource.axd included in your ignoreUrlPrefixes in Sitecore. It is used to serve resources embedded in assemblies, anything from javascript to images - atlas and some of the asp.net 2.0 rich controls won't work otherwise.

SDN5 site received a minor facelift and become a bit more firefox firefox 1.5 friendly. If I've broken anything, let me know.


Update: It looks like the layout is broken on Firefox versions < 1.5. Upgrading to 1.5 helps.

SDN5 gets rss feeds, done using Sitecore RSS Module. Check out and subscribe to downloads feed to get notified of new releases. Still need to find a place to stick pretty 'xml' button to.

Finally making use of DefaultButton of asp.net's Panel: searching at sdn5 should work fine with enter button now. If there are other places where enter behaviour should be fixed, send them in.

Speaking of search, sdn5 search autocomplete is finally live. Fixed the issue with list buttons appearing in IE after you hower over menu while autocomplete box is displaying (reported by Alex de Groot, thanks).

Microsoft released the Web Application Project for Visual Studio 2005, which is probably the best option you have working with Sitecore 5.2+ in MSVS. Download.

Very cool Microsoft's Monad shell gets RC1 under a brand new 'Windows PowerShell' name.

I used to have a CopySourceAsHtml visual studio add in to post sharply formatted code to blog. But it produced really dirty html which actually made my dasBlog unhappy and for some reason it doesn’t work well (or just doesn’t work) in vs2005.

Here’s a really nice macro on coding horror that works in any visual studio version and creates a much cleaner code. It’s a bit painful to install, but then you can assign a shortcut and forget. Mine is ctrl-c + ctrl-c.

Update: which wasn't a great idea for a hotkey..

I’m using asp.net 2.0 portal on Sitecore front end in the current project, and personalization features such as portlet drag-n-drop just won’t work unless asp.net understands that the user is logged in and can tell the difference between users.

Here’s my hack-n-slash solution: it envolves shim classes implementing IPrincipal and IIdentity, delegating everything to Sitecore. User id is returned as user name to asp.net, so that each user gets own personalization data (actually user names would also work, since they're unique). On each request, a custom processor in HttpBeginRequest pipeline (named AspnetUserSetter) puts the Sitecore principal in asp.net context.

And since I'm humble enough to allow asp.net do the rest, using default personalization database and provider - it just works. Now I wish it was easier to create custom frames around web parts.