Typed Code will be more Strict in 16.03 (slightly breaking change)

The new Typed mode will become even more strict in 16.03 and get a slight (breaking) rename. 

TL;DR

1. The base classes will be renamed from RazorPro, ApiPro, CodePro to RazorTyped, ApiTyped, CodeTyped
2. This does affect the latest released Blog and Mobius Forms app which already used these base classes - but it's easy to fix.
3. By default every access to a field, like item.Get("Color") will throw an exception if the field doesn't exist.
4. But if you do use such a field, you get some really nice extensive help 😏
5. The method .Parents(...) has a confusing API because the parameter order is reversed to .Children(...). There's a logic to this, but it's easy to make mistakes. Because of this, the parameter names will be required.

Remember: all these changes only affects new Typed Code. It doesn't affect any existing code which was dynamic. 

Base Class Rename

We had just released the new base classes like RazorPro in 16.02, but soon realized that it got people confused. When we presented it to a group of fans in early August, a concern was that it appeared to be a premium feature. 

In addition to this, we noticed that writing documentation was also confusing, as we had to always refer to it as Pro/Typed mode. Because of this, we decided to do another round of renames, but this will mean some errors if you upgrade from 16.02 to 16.03. 

😥 Sorry for this, but we believe it's best for long term. 

Breaking Blog 06.03/06.04 and Mobius 05.07.02

These Apps are already using the base classes RazorPro, ApiPro and CodePro. Unfortunately this will now throw an error pointing the users to this page. Please replace those names with RazorTyped, ApiTyped and CodeTyped.

😥 Sorry for this, but we believe it's best for long term. 

Strict Field/Property Access

As we refactored all our apps to the latest Typed conventions, we noticed something ugly: There were at least 10 cases of code which referenced fields that didn't exist any more. The code would often be about optional fields, eg:

<h2>@main.String("Title") @sub.String("AdditionalTitle")</h2>

The problem with this code was that the sub object didn't have an AdditionalTitle field any more. This was probably something that had been introduced a while back and decided against, but the code remained and people kept maintaining it, even though it was useless. 

We also found if-statements and other things which did checks on fields that simply didn't exist any more. 

Since the old paradigm "just return null if not found" was a bit too magical and led to bad code, we decided that we should make it strict in the new typed mode. So the new behavior is as follows:

• item.String("something") ➡️ Exception with additional help
  item.Int("something") ➡️ Exception with additional help
  If you try to access a property which doesn't exist, an exception will be thrown by default.
• item.String("something", required: false) ➡️ null
  item.Int("something", required: false) ➡️ 0 (zero)
  In this case it will still return a null, since the developer explicitly didn't care if the field exists.
• var loose = AsItem(item, strict: false);
  loose.String("something") ➡️ null
  loose.String("something", required: true) ➡️ Exception
  loose.Int("something") ➡️ 0 (zero)
  If an item is created with strict: false the system assumes the developer wanted this behavior, and will be ok with it.

This will help to capture many code bugs at development time 💃🏽🥳.

In addition, it will stil work for advanced scenarios where missing fields are expected. For example, if you have RealEstate entities with Name, etc. and House entities with some additional fields, it's common to loop all and only show the properties which exist. 

Improved Help

We've made two nice improvements

1. The cshtml-file is marked in the error message so it's easier to spot the line with the bug
2. If you're accessing a field that doesn't exist, a help in the toolbar will tell you what the code was trying to access and what fields do exist. 

.Parents(...) requires named parameters

Items have methods such as .Children(...) and .Parents(...) to retrieve related data. Both of these methods have 2 optional parameters:

• field - used on Children to find all the children in this field; it is the first field as it's used a lot
• type - used on Children to limit the results to Entities of a specific type; it's an optional second field which must be named, as it's not used much.

But on Parents the order is reversed, because when an object is looking for parents, the need is usually different. On on .Parents(...) the type is more commonly used. For example to find navigate from a Tag object to find all BlogPosts which use this tag. Since the order was reversed, it was easy to make mistakes, so now the .Parents(...) will always require all parameters to be named. Examples:

• item.Parents() will work and get all parents
• item.Parents("BlogPost") will now error
• item.Parents(type: "BlogPost") will work

TL;DR 2

We believe that making the code much stricter will help all future code be cleaner and more robust, so do try out the new typed code and we'll try to get it fully stable and LTS very soon!

Love from Switzerland and Croatia
iJungleboy, Tonci, Duje