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.
###Supporting Habitat
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.
1 | <configuration> |
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 /app_config/include/fortis/fortis.config.
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:
1 | <models> |
Patch example:1
2
3
4
5
6
7
8
9<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<fortis>
<models>
<model patch:after="*[name='Fortis.Model']" name="MyFeature.Model" assembley="MyFeature.Model, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</models>
</fortis>
</sitecore>
<configuration>
###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:
1 | <fieldTypes> |
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 IFieldWrapper.
###Other changes
Issues from GitHub:
- #23: The
.Valueproperty on theTextFieldWrappernow returns the raw value as a string rather than running through theFieldRenderer. TheRichTextFieldWrapper.Valueproperty has been changed to return anIHtmlStringand renders the rich text content withEditingset to false. - #19: The
IItemFactory.Savemethod has new overloads to match the.Save(bool silent)and.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!
– Richard.