Cleanup of orphaned Property Bindings



When an author selects to use a specific type of automation in their Pattern Model (i.e. they select a Command, or a Condition, or a Value Provider etc) in any of the many places where these are configured (i.e. on the Type of a Command Automation or LaunchPoint, in the Conditions of a LaunchPoint, on the Value Provider of a Variable Property etc.) the 'designtime' properties of that specific type are persisted into the Pattern Model file. And the author can configure the values or configure a ValueProvider of these Dual-Value design-time properties.

Note That if the author selects to use a ValueProvider for any one of these design-time properties, this will create a set of nested child design-time properties as well (and this can recurse as more descendants are configured through descendant ValueProviders). This mechanism is well supported all over the pattern model, and the sites this will occur in the PatternModel is expected to increase as we add more automation features over time.

However, if the author changes the automation type (i.e. of the Command, LaunchPoint, ValueProvider, Condition etc) a new set of design-time properties are persisted alongside the current set of design-time properties that represented the previous automation type. The previous set of design-time properties are no longer part of the definition of the current automation type and are now 'orphaned' from their orginal automation type.
These orphaned design-time properties will remain persisted and will build-up noise over time as the Pattern Model is refactored. These orpahned design-time properties will not be removed automatically.


Add code that removes orphaned design-time propertires when the Pattern Model is persisted, or when the automation type is changed.

This mechanism needs to be implemented in one place in the code related to design-time properties as a general purpose cleanup mechanism, so that it is not duplicated all over the codebase.


dcazzulino wrote Mar 14, 2013 at 2:45 PM

When users change the automation type, we clean. It's not frequent to change automation types just to try something different... And I don't think anyone expects the existing values to linger and magically come back like they were as they change types.

Alternatively (and more complicated), we could still keep them in memory, but only serialize the ones that exist in the automation type. This means that while they keep the designer open, we do preserve everything so they can go back&forth as many times they want, but upon close/reopen, those are lost.

jezzsa wrote Mar 20, 2013 at 4:21 AM

I like the second option best - cleanse on persistence.

I recall myself when building some toolkits and going to refactoring them, and changing the command type for example from UnfoldVsTemplate to GenerateT4Code, and being able to see the same properties (that are shared) assume the same values is nice and really noteable.
So I would opt for option 2 above.

The next challenge would be determining exactly where in the new code we perform this 'cleansing' for all bindings (regardless of where in the pattern model they are defined, and at whatever level of nesting they are at)??

Anyone have any ideas?

jezzsa wrote May 7, 2013 at 9:15 PM

Update [08/05]

zteven has just discovered that in switching between a GenerateCodeCommand to an UnfoldCommand (seems like a common enough thing to do as an author), that two of the properties which are left behind from the GenerateCodeCommand (TargetBuildAction and TargetCopyToOutput) are for some reason being validated at runtime, and causing the UnfoldCommand command to fail at runtime.

I think we need to get this one fixed ASAP, and have persistence or validation of the model remove these orphaned properties.

dcazzulino wrote May 7, 2013 at 10:06 PM