Estimated reading time:
We are working on new version of Fortis so I’m going to do a few posts to highlight the new improvements. If you have any feature requests please make sure they are added as an issue/request on Github: https://github.com/Fortis-Collection/fortis/issues.
A breaking change to Fortis is how the configuration is handled. Previously, the core Fortis package modified the
web.config to add a section that allowed the developer to identify the assembley that the Fortis model classes were held in. This limited the development team to a single assembly for all the models.
This was limiting to the development team. It meant that you could not build a module using Fortis and install that to a Sitecore implementation without serializing the templates for the module in your site and having the model classes for the module in your own project.
Recently the big talking point has been Sitecore Habitat and how that is archtected into Features/Components. Again, having a single assembly forces all the model classes and interfaces to live in the same project, breaking the architectural pattern.
In Fortis V4 this has all been changed. To be more aligned with standard Sitecore modules, we have moved the configuration out of the
Web.config and into an include file. This file lives by default in
Also the models can now live in multiple assemblies. This is done by adding each assembly to the
models list in the config. Because this is now inside the Sitecore config, you can do this via an include file for each of your modules:
###Custom Field Types
Another bug bear has been dealing with custom field types in Fortis. Previously the field type support was hard coded into the
SpawnProvider. To support a custom field type you would have to roll your own
SpawnProvider and implement the
GetField method for your field type.
This has now been moved to the configuration:
Now its as simple as adding a new
field to the config to support a custom field type. Again, this can be patched in via an include file. If the custom field type stores its Raw Value in the same way as one of the in built fields, you can just use one of the existing
IFieldWrapper classes. Or you can roll your own field wrapper as long as it implements
Issues from GitHub:
- #23: The
.Valueproperty on the
TextFieldWrappernow returns the raw value as a string rather than running through the
RichTextFieldWrapper.Valueproperty has been changed to return an
IHtmlStringand renders the rich text content with
Editingset to false.
- #19: The
IItemFactory.Savemethod has new overloads to match the
.Save(bool updateStatistics, bool silent).
- #18: Added a new
.HasValueproperty that can be used to check if a value is blank or has not been assigned.
###Unit Testing Changes
Finally we have made some changes to the unit tests. Previously the unit tests had been created using Microsoft Fakes, but this relied on the developer having a Visual Studio Ultimate edition or higher. These tests have been removed in favor of using Sitecore FakeDb. This will make the unit tests more accessible to developers that do not have access to the ultimate editions of VS. More tests will be ported to the new version in the coming weeks.
This has now been released on Nuget as v4.0.0-beta3 - have a play and let us know what you think!
Well thats all for now - there will be more updates coming soon, please submit issues or feature requests on Github or hit us up on Slack!