public static PropertyInfo<string> Name2Property = RegisterProperty<string>(p => p.Name2, "Name2", null);
The "null" at the end of the assignement means the default value is null.
There are two ways to assing a default vale to PropertyInfo. One of them is the one in your sample. The other is on the DataPortal_Create/Create_Child. When writing the C# templates I favoured the later as the former only allow static values. To illustrate
what I'm saying, try to enter _lastID in the default value of a PK property. You get
#region Static Fields
private static int _lastID;
and on DataPortal_Create() you get
LoadProperty(FolderIDProperty, System.Threading.Interlocked.Decrement(ref _lastID));
This doesn't work as it should if assigned on the PropertyInfo declaration as it is assigned statically and always returns the same value.
As you might know from reading Rocky's posts on the forum and on several release notes, over the years he succeeded to reduce the amount of code you have to type and that is a major concern for him. Assigning the default on PropertyInfo declaration has a
clear purpose of avoiding the need for the DataPortal_Create method. It's a good solution if you manage to set all your defaults this way. But it only answers the requisite for fixed value defaults. If you need default values that aren't fixed i.e. that
change according to whatever conditions or that are loaded from the database you still need to use DataPortal_Create method.
Since we are code generating, there is no need to use these techniques that were designed to reduce hand typing. If these techniques have some disadvantages and you can avoid them altogether...
One might argue that CslaGenFork should allow the option of using one or the other way of specifyng defaults. And "one" might be right. It should be done at the project or object level, as it would be too confusing to set default values
both ways. You would have two places to look for the default value. If you need one single default specified in DataPortal_Create, all of them must also be there. For me it isn't clear enough we need any alternative to the DataPortal_Create way.
Back to the point, you can always set the default to null and it will show up in DataPortal_Create. So this isn't an issue. The REAL POINT is whether or not CslaGenFork templates should presume that a string type property marked as nullable should have a
NULL value by default (unless you explictly say otherwise). This is a good and valid pont. This default will be set in DataPortal_Create
Using GetValue instead of GetString is also a valid point.
This will be promoted to Work Item