In a previous post about extending Glass Mapper to handle custom data types I shared some code which I felt was overly verbose and I did not like the amount of code that had been copy/pasted. The example I used was a fairly trivial one, but it’s always good practice to try avoid copy/paste in case some point in the future the base implementation is changed. It might not always be clear to future developers how that piece of code had come about.
In that original post, Mike Reynolds (a.k.a sitecorejunkie) suggested use of the Decorator Pattern to wrap an instance of the base mapper and delegate some of the methods. Well it got me feeling uneasy and I finally found a little time to come back and clean that code up, I went a slightly different route and decided to use constructor overloading.
On a recent project I needed to add a couple of fields to Media Items templates in order store some additional data. We are using the Glass Mapper ORM in our project and out of the box there are two fields which we can map to: Image and File. I also needed to retrieve the file size, which neither of these fields returned either.
It turned out to be relatively simple to extend Glass Mapper and add our own custom data handler to map the additional fields.
I recently upgraded a project from Glass Mapper v2 (
Glass.Mapper.Sitecore) to Glass Mapper v3 (
Glass.Mapper.Sc). I’ve been fortunate enough to be using Team Development for Sitecore (TDS) with most of my projects over the past few years, which really simplifies generating a default set of Glass Models using the T4 Templates which are available from the Hedgehog Codegen repo on GitHub. The upgrade process was simple enough (NuGet FTW!) but thought I would share some issues I came across that took a little bit of time to resolve.
The upgrade was to fix some unrelated issues we were facing, but since the v2 Glass project seems to have disappeared off the face of the earth (annoying that an entire GitHub repo just gets deleted like that rather than left for historical purposes…) it seemed like a good idea to remove this dependency at the same time.