During the 2013 SDL Tridion MVP retreat I’ve worked on the FBI extension, also known as the BFF framework. Now some of you might think that all the MVPs do during that event is drink and have fun, which is actually right. The MVPs, love SDL Tridion, they love to code, they like to have fun and they enjoy a drink while they talk. So while at the retreat, they are actually in their natural element since everybody likes the same things and those things are all actually done during their stay (sometimes at the same time). Mind you coding and drinking don’t always mix, liquids dripping out of a laptop is one of the least fun things we actually saw this year.

If by now you are wondering what the MVP retreat is actually all about, or what/who the MVPs actually are, take a look here. If that awakened your interest and you wonder why you aren’t an MVP, keep this in mind; all it takes is a nomination (you can nominate yourself!), without a nomination, you won’t be considered. If you feel intimidated by all the knowledge that the current MVPs have, don’t be! Being an MVP isn’t all about having a lot of SDL Tridion knowledge (sure it helps), but it actually is all about actually sharing!

Okay enough with the actually, now back to FBI and BFF. On the LinkedIn SDL Tridion Professionals group, Nuno Linhares asked the community what the MVPs should focus on when choosing their new open source project during the 2013 retreat. Most votes went to the Custom Content Editors Screens, which initially was suggested by Ron Grisnich I believe (who at the time of writing this, hasn’t joined the project yet ;)). So the MVPs joining this project, talked about what Custom Content Editor Screens actually meant and what they could do to give shape to that definition. Since one of the other projects was already called TiTS & ASS (something to do with Testing Templates & Assertion), we couldn’t stay behind and came up with Field Behavior Injection and Behavior Field Framework.

Our idea was to build an open source framework that could be used to easily customize the Editor screens (of a Component for example). A often asked question is if you can make a Component field read-only for a certain group of users. Now while there are extensions out there providing you that, it isn’t delivered as a complete solution. Technically it is a bit difficult to actually create a complete solution, since there could be so many customizations that you can have, so a framework makes sense. With the framework we came up with, you can inject new behaviors to a existing field. The first one which is being developed is marking a field as read-only for a certain group of users. For the future you have to think along the lines of hiding fields, grouping fields and perhaps even customizing the view of a field (a slider for a number field instead of a text value). Now we got a lot of code done already, but it isn’t finished by far. So before I continue to give a little explanation of what there is, let me start of by saying: IT IS OPEN TO JOIN FOR EVERYBODY! Please mail one of the current owners and ask to be included in the project. You can join in just to see the progress and add to the discussions, or even help out finishing the code.

At this moment we have a Visual Studio solution for the UI extension(s). You will find a FBI.Base project which contains some helper classes like a Core Service client. The FBI.Editor project currently is mainly focused around the Schema field extension, adding the ability to mark which behaviors you would like to enable for which Groups per Schema field. The FBI.Model project is currently not used, but there to complete the view, this way we can easily connect to the SDL Tridion core if required. Last we have the FBI.Validators project, this contains some (client side) validation rules we can add to Schema fields (an alternative to using Schema facets).

When adding this extension to your CMS (a installer script will be added soon) you get on every Schema field, additional Validation and Behavior properties. Right now there still is a lot of work to do, but the basics of the framework is there. Simple tasks (if you would be willing to pick anything up) would be things like moving all label texts into the resource bundle. On the more complicated side we need to finish up the example of the read-only field in what we call a 360 scenario. Currently the Groups are hardcoded (they need to be read from the CMS) and when set, we need to extend the Component tab, to make the field there actually read only (for the specified Groups). So see this as an open invite to join in and create this a true open source community project. As said before, you don’t need to have in depth knowledge to join, also people who want to discuss features and help out with documenting are welcome.