In this post I will be looking at using Lucinq to drive search using the default sitecore 7 indexing.
Lucinq provides the ability to use the generic forms of the standard Term, Phrase, Wildcard and other methods. This allows the assignment of an expression to denote which of the fields is the target of the query.
In the line below, you can see an example of this in action
queryBuilder.Term(t => t.Content, "value")
This tells Lucinq to read the IndexField attribute from the Content field of the SearchResultItem class and use that as the field for the Lucene query that is to be sent down.
* Note, the .HasBaseTemplate() method of Lucinq’s query extensions requires a change to the default Sitecore indexing settings. *
Here is an example in situe – this can be can in unit tests WITHOUT the need to run the sitecore initialise pipeline (unlike SC 7 search).
// the index lives in the appdata folder, so using a Server.MapPath to get the real path for Lucene.
string searchIndexPath = Server.MapPath(Settings.IndexFolder + @"/lucinqwebindex");
using (SitecoreSearch search = new SitecoreSearch(searchIndexPath))
ISitecoreQueryBuilder queryBuilder = new SitecoreQueryBuilder(SitecoreMode.Sitecore7);
queryBuilder.TemplateId(ContentIds.HomeTemplateId); // add template id to the query
// below users the sitecore index field attribute, its the same as
// queryBuilder.Term("content", "value");
queryBuilder.Term(t => t.Content, "value");// set up the term based on the in built sitecore 7 class.
ISitecoreSearchResult searchResult = search.Execute(qb);
int totalResults = searchResult.TotalHits; // gets the total number of results
List items = searchResult.GetPagedItems(1, 10);
More information can be found on Lucinq on github here
In this post I describe the process for creating custom permissions on the Sitecore platform. Why? I hear you ask… Well this I have found particularly useful when you want something in between an end user being able to ‘Read’ an item and not being able to. Consider a situation where instead of redirecting your end user to the login page, you can instead present ‘teaser’ content about why they should be joining up, and what they would gain by doing so. Furthermore, you could extend this to use conditional renderings to allow certain areas to hide or replace their data source giving a snapshot of what the page would look like if they sign up to your premium service. There are no doubt hundreds more use cases, but this particular one I have had requirement for more than once and it seems to be an elegant way to solve the problem.
At its core, Sitecore relies on the web.config to provide the necessary permissions for items. This allows extending this permissions set to create your new permission(s) to be little more than adding an additional element in the appropriate section within the web.config or config include.
<rights defaultType="Sitecore.Security.AccessControl.AccessRight, Sitecore.Kernel">
<!--My custom access right-->
<add name="item:newpermission" comment="New permission for items." title="New Permission"/>
By doing this, you should now find that ‘New Permission’ now appears as a right in the security editor.
In this post I will cover using Lucinq with sitecore – in particular returning the results through the Glass Sitecore Mapper.
Returning results from lucene is something we as Sitecore developers have been used to for some time. Lucene provides hyper fast searching and its flexible storage makes it great for indexing content. However, in use, the API is somewhat verbose and not necessarily the easiest to understand without reading up on it first (I still would recommend the book Lucene In Action to get a grounding in the product).
I have a few issues with the search layers that Sitecore have implemented over the years which I won’t go into in this post.
I make no secret of Glass Mapper being my current ORM of choice on the Sitecore platform but recently (not for the first time) I came across the need to control the mapping process in a crazier manner than Glass allows out of the box.
Glass provides a good set of structures to allow you to extend its behaviour when it comes to the mapping process and I utilised this to hook in and provide a ‘Delegate’ fluent mapping. This mapping allows you to delegate the behaviour of the mapping process back to code you control using a simple mappingContext.Delegate(x => x.MyField).GetValue(y => GetMeTheField(y.Item)). This is similar to the mappingContext.Field() or mappingContext.SitecoreInfo() methods that Glass Mapper provides out of the box.
Ever wondered how to resolve your command / pipeline entry from your IoC container? One of the more common arguments I have seen for the Service Locator (anti) pattern is for exactly this reason, and it’s completely avoidable. This approach works perfectly well with the likes of Castle Windsor, Autofac, Unity or even Agnostic IoC. This also provides the added bonus of being able to unit test your pipelines, which in my humble opinion is possibly where it is needed most. It also allows you to utilise constructor injection in Sitecore Pipelines (which I have heard from seasoned Sitecore developers can’t be done 😉 ).
In this post I describe how to give control of your dependencies on pipeline & commands to your IoC container of choice using Sitecore factories.