Life Through a Lens – Lesser known Glass Mapper features

Mapping types

[SitecoreNode] / Node() – This mapping type allows you to map to another item in Sitecore directly by the string representation of id as a guid or by its path. You would typically map this to another Glass mapped type.
[SitecoreLinked] / Linked() – This mapping type allows you to map to an IEnumerable for items that are linked to the mapped item (think navigate > links in the standard Sitecore ribbon). This (using the configuration options) can be referrers / referred to items.
[Ignore] / Ignore() – this can definitely be handy for example when injecting content from external sources into your models from controller code.

Supported types
Whilst not mapping types, Glass can indeed map to types that are not quite so commonly used.
RuleList – if you map to a rulelist (technically a [SitecoreField] mapping) then you can actually get out a usable set of conditions for use in the Sitecore rules api.
Nullable Mapping – Glass Mapper has long supported mapping to nullable .net types (e.g. int? or Nullable), this includes the majority of regular mappings with HasValue generally referring to whether the Sitecore field was empty or not.

Typed Edit Frames
“Because I am lazy” is the best and most useful introduction to a feature I have seen in a while – brought to to from this V4 Demo at around 26min 15secs. The whole video is well worth a watch, but it shows them in use. Typed edit frames though are a feature to allow the creation of edit frames based upon Glass models.

Mapping to / from external data

One of the great advantages of Glass models being detached from Sitecore (unlike most wrapping based solutions) is the ability to map data from external third party solutions. In the Glass Mapper tutorials, there is a great example of mapping Glass Mapper objects using external data.

Data transfer between environments

Another great advantage of Glass models being detached from the Sitecore item is that, using a Glass model, you can breach the master / web boundary or even environment boundary. So, for example, it would be perfectly easy to write a web service (maybe for transferring data from web to master for the purpose of saving user submitted FAQ’s for example), that would construct a Glass model on the web node, post it to the master node and save it using regular Glass code.

Model Caching
Model caching was primarily designed to allow the caching of models that are used in locations that cannot use regular Sitecore caching. This could be for example, a rendering that contains a form and would thus need to respond to postbacks etc.

Configuration Maps
Configuratioin maps are a wrapper for regular Glass fluent configuration that allows better separation from the models, it was covered in further detail in V4 – Configuration Maps

VersionCountDisabler
The version count disabler is a simple structure that allows Glass to behave a little more like the standard Sitecore API, in use it is really this simple

using(new VersionCountDisabler)
{
   var whatever = sitecoreContext.GetItem<IWhatever>(); // this code will get the item even if the version count is 0
}

More information on version count disabling can be found at Glass.lu – VersionCountDisabler

Typed Glass Controllers
A relatively recent addition to Glass Mapper has been the addition of a typed GlassController, this was described further in Unit Testing with GlassController

Further Reading / Watching

Glass Mapper V4 release post
Glass Mapper V4 release video

Life Through A Lens – Using your own IoC container with Glass Mapper

This should be a nice quick post, but when I look back, it’s something I have done on every project I have used Glass Mapper on.

Glass’ out of the box Castle Windsor implementation tends to create it’s own IWindsorContainer during Sitecore’s initialise pipeline (formerly done using WebActivator). This is great if you want to get up and running quickly, but in my case – especially with the new Delegate mapping function available, I often find that I would rather have a more global container than this, since – for example, some of the delegate mapping does use dependencies from my codebase.

In this post I will quickly describe how to use an external Castle Windsor container with Glass Mapper. If you want to find out more on using other IoC containers including Autofac, StructureMap or Unity as the container for Glass, please take a look at Glass Mapper On Agnostic IoC

Continue reading

Life Through A Lens – Unit Testing your .net code using Glass Mapper

So now I have gotten my first couple of Sitecore User Group presentations out of the way – I thought I would actually continue on my journey of showing how I use Glass Mapper on the Sitecore platform in real world application.

As you will see from other posts I write – I am very much a TDD advocate. I find it helps focus my mind much better than simply writing code ad-hoc. Also – I hate testing, but love coding – so what better way to get my testing done than coding.

In choosing an ORM, I believe this should be one of your primary criteria since you are going to take some sort of performance hit with it being in the way and for me, trying to justify as just being ‘prettier’ code doesn’t really cut it when you are presenting it to a wider team.

With this in mind, I thought I would kinda tie these two together and look at how I use Glass to perform unit testing on *MY* code.

Continue reading

Life Through A Lens – Component Parts

So – following on the first part in my series on how I have been using Glass Mapper for Sitecore in the real world.

Glass Mapper
Just a couple of quick notes on Glass Mapper, the Glass Mapper developers have done a great job of writing tutorials on most aspects of Glass, and I expect with recent developments on the project, this will only get better, so please check them out at www.glass.lu.

Firstly – Whilst Glass supports using classes for mapping, I almost always use interfaces to represent my model objects, this is due to their multiple inheritance structure and it allowing better representation of the templates on which they are to be based.

Secondly – I almost always use the fluent configuration API – however… I almost always choose to configure this using my Glass Mapper Maps project (described below)

Finally – I like to turn the Automapping feature off for the most part, this is probably because I am a control freak :D.

Glass Mapper Maps
I have been in many discussions with the developers at Glass and I am hoping that this is one of the improvements that they will consider rolling into the product as a whole. Whether this is the case or not – here is what they are and how I use them.

Glass Mapper Maps are a neat solution to isolating the domain objects for use with Glass Mapper. Generally in practice, I start off by creating 2 projects in Visual Studio, these are:

  • xxx.Model
  • xxx.Model.Mapping

In xxx.Model, I would add my regular domain objects – so, ISitecoreItem, ITitleAndIntro : ISitecoreItem, IMetaData : ISitecoreItem

Agnostic IoC
Agnostic IoC is an abstraction layer to allow modules to utilise an unknown final IoC framework, this means that I can perform my registrations and resolves against Agnostic IoC and it in turn performs them against the container of choice. It does this by means of Nuget Packages.

With Glass Mapper, this means that I can use Glass with multiple clients complying with their restrictions of IoC container – be it Autofac, Unity, NInject, StructureMap or pretty much anything else. It also has the upshot of including it in the project, so any module development I choose can also be portable.

So now when I install Glass I need at least the following Nuget Packages

  • Glass.Mapper
  • Glass.Mapper.Sc
  • Agnostic.IoC

Wherever you actually want to perform the initialisation for Glass you also need to include the ‘Translator’ package, so for example – Agnostic.IoC.Autofac. You do not need this in any projects that are not performing the initialisation.

For a more in depth description, please visit Agnostic IoC

Conclusion

In the next post I will be looking at getting Glass Mapper up and running in your solution fully.

May I also draw your attention to the fact that the Glass Development team will shortly be offering training and consultancy on their products which I would highly recommend if you get the opportunity.

Glass Mapper – Introducing Glass Maps

This is due to be released in an upcoming module (along with the delegate mapper described here), however – here is a sneak preview of what I have been working on for Glass Mapper.

I think Glass Mapper is a fantastic and versatile ORM for Sitecore, however one of my slight bugbears with Glass Mapper as it stands is this. I want to build my POCOs as isolated as they can be. Glass Mapper has provided a fluent API which is grand, but the implementation by default leaves it a little short in my humble opinion. Out of the box, it’s a bunch of configurations that you add to the GlassScCustom (or in your own) class. In addition to this, if you want to support inheritance – say IExtendedSitecoreItem : ISitecoreItem you have to define all of the mapping for ISitecoreItem on IExtendedSitecoreItem as well. There are ways in Glass to sort this – using imports and the like, but you can end up with the framework excepting if you import the same thing twice. For me, I wanted an interface similar to that of fluent nHibernate, using a mapping generic to provide the mappings in an isolation from the original POCOs so I have created just such a thing:

Continue reading

Agnostic IoC Pt 1- Building Glass Mapper for Autofac, StructureMap, Windsor By Changing 1 Nuget Package

As a few of might already know, we started a project a short while back to overcome the difficulties developers face when building reusable modules for systems. This project was centered on the need to continually write our inverted dependency calls manually to avoid ties to an IoC container such as Autofac / Windsor. Recently a client of mine and also a friend have independently approached me about this subject. The former wants to commission me and Simon from the team here, to help them out on a build for a client of theirs, this client has asked that we use Autofac as the dependency container and Glass Mapper as the ORM. The second wants to be able to use Glass Mapper with their current implementation, they however use structure map.

It would have been a reasonable enough task to duplicate and modify the Windsor implementation from github twice to allow this to happen, but I fancied a challenge and thought this would be a good test of the Agnostic IoC extensions that I have written and talked about Here. After all, it is the near perfect use case for such an implementation – 1 framework with a choice of end IoC containers depending on the client.

What is Agnostic IoC?
Agnostic IoC is a set of extensions that aims to abstract the IoC container away from the final consuming implementation, you write your code against Agnostic IoC and it adapts the calls to the real IoC. You can initialise it from self discovery on adapters or simply push in your own already built container. It in many cases will not replace your own IoC implementation, it’s primary focus is to allow you to ship your reusable modules so others can enjoy them without tying them to particular versions of IoC containers. If the IoC container of your choice isn’t supported, it is quick and easy to write an additional one simply by inheriting from the abstract ContainerManager class. When consuming the application, you simply need to install the nuget package that matches your chosen IoC. If you need to get at any of the original functionality – the ContainerAdapter is a generic in its own right, you can simply cast something like myContainerManager.Container as IWindsorContainer to get back to the original container (that said – you can push your own in so not sure how much use it will be 😉 )
Continue reading

Controlling glass fields from your own code.

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.
Continue reading