I’ve been working a lot on Sitecore development infrastructure recently and package management is one of the areas, particularly NuGet.
Unfortunately, Sitecore doesn’t provide any feed that you could use right away. so carrying over Sitecore DLLs in a repository is a standard practice that I’ve seen for few years and actually been using.
So I decided to create my own packages and here how I did it.
Continue reading “Generate NuGet packages for Sitecore releases via PowerShell”
In my previous post, I’ve described the benefits of composition pattern over inheritance in code generation and mentioned that it simplifies restoration of models from reflection. From my point, this is a huge plus as it enables the creation of developer friendly modular architecture in Sitecore.
I do not think that someone still has problems with a creation of an update package with Sitecore config transforms, but it is not really possible to install an update package in your Visual Studio solution. Of cause, you can install it in Sitecore, grab all libraries from bin folder and copy to your source, then serialize installed items into your project, generate your models based on “everything” you have in Sitecore.
To me, it doesn’t sound like a good approach, moreover, there are many of solution like NuGet, npm, bower that drastically simplify package management and installation for development. Also, when referencing items from packages, you don’t expect to modify DLL coming with them, so I do not think that you should have to serialize Sitecore items to use them in your model generation.
Most likely you already have information about your templates in compiled into your module DLLs. Below you would see how you could use it.
Continue reading “Generation of a Composite Model Using Reflection and Sitecore Serialization”
If you do Sitecore projects and have never tried to create strongly typed models then most likely you are doing something wrong. 🙂 Why? As soon as your project grows a bit, the logic becomes more complex or you decide to refactor a few components, you will suffer from all magic things – strings, number, GUIDs. Of cause, there are a few things that you can do about that. Continue reading “Composite Reuse Principle in Sitecore Code Generation”
As I’ve mentioned in a previous post, my team and I are working on Sitecore Commerce StoreFront migration to Sitecore Habitat.
Before we actually moved to code itself, we dug into codebases of both projects to review their “as-is” implementation and we decided to come up with a plan on how to go to map functionality to Habitat so that it would comply with the principles it suggests. And here is what we found out and came up with. Continue reading “Mapping Sitecore StoreFront to Habitat”
I was playing with Sitecore solution & projects setup and configuration, I faced a need to alter code generation logic used in it. We use TDS for content synchronization as well as it’s code generation engine build on T4 text templates.
While T4 is great for code generation, it is not as straightforward to debug them as it might be expected. So let me describe how to do this.
Continue reading “Debug TDS code generation templates”
Sitecore is quite a hot topic at in our company. We have a lot of impressive initiatives going on: platform education programs, an optimization of project implementation approaches, formalization of development best practices, various accelerators from project starter kits to integration external systems covering different aspects of digital marketing and commerce, just investigation of new technologies and their potential applications to Sitecore. Beeing an R&D solution architect in Digital Engagement practice, I’m fortunate to be in the middle of those activities.
One of my projects now is an exploration of Sitecore Commerce and StoreFront as it’s reference implementation. About a year ago I’ve touched it a bit during hybris integration POC, unfortunately, that time it didn’t go any further than that. So now it’s time to get back to Sitecore Commerce Connect module.
To make this exploration more interesting we also decided to add to the mix Sitecore Habitat and apply principles and techniques that it defines and promote to a simple commerce implementation.
Continue reading “Inception: Sitecore Storefront to Habitat Migrating”
It is quite a standard approach that you can see in many CMS project now – designs, UX, and HTML is done upfront or way in advance in comparison with CMS development. You might think now about Agile and say that all done almost simultaneously within one iteration, but even in this case, you would need to have HTML done before it would be converted into your Sitecore rendering.
In addition to that, there is a huge shift towards front-end technologies which affect Sitecore projects as well. Being a big advocate of a full stack developers that are knowledgeable enough in both Sitecore and front-end technologies used, I still see a lot of cases when Sitecore and front-end code are done by different developers with completely different skill sets.
All of the above creates a problem of integration of deliverables and maintenance from Sitecore and front-end developers during a project timeline:
- double work of updating HTML and Sitecore views
- update HTML directly in rendering or in HTML repository and ask Sitecore developer to add his changes
- sometimes work even done in separate repositories which make versioning and branching look like “mission impossible”
- testability of a front-end code isn’t great and not always make sense if errors might be introduced during copying of HTML to renderings.
To address those issues there should be a better way of front-end code integration into Sitecore.
Continue reading “Using AngularJS directives in Sitecore edit mode”