none
Dependency Property naming conventions not required?

    Question

  • Because I didn't like all the duplicate code of creating a dependency property I decided to create a factory class to simplify this. I came across possible problems involving the naming conventions for the dependency properties and it's CLR wrapper while reading through the MSDN documentation. (http://msdn.microsoft.com/en-us/library/bb613563.aspx)

    This however doesn't seem to affect my implementation at all, as described in detail on: http://whathecode.wordpress.com/2010/10/25/dependency-property-factory-part-2/

    My questions are:

    1. Does anyone know concrete examples of problems caused by not following the convention of naming your CLR property wrapper the same as the dependency property?

    2. How is it possible for my property to still work when I don't have the identifier field in my class directly anymore? According to msdn XAML processing uses the static field identifier, but all evidence indicates that it only needs the correct name as passed to the Register method.

    Monday, October 25, 2010 2:29 AM

Answers

  • Steven,

    The DP system is going to use the terms your factory used.  Since you still have to register the DP, it has the name set appropriately (internally) from the registration call.  However, I would recommend not bypassing convention in this case, even if it works...

    The DP system has rules (by convention) that are clearly documented.  Even if your factory works now, there's no guarantee that it will work with Silverlight, or with WPF 5 later (or even a service pack).  Going against convention is always problematic - sometimes it works, but then will break later (when you don't know why).

    -Reed

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    • Marked as answer by Steven Jeuris Monday, October 25, 2010 6:09 PM
    Monday, October 25, 2010 5:53 PM
    Moderator

All replies

  • 1. Does anyone know concrete examples of problems caused by not following the convention of naming your CLR property wrapper the same as the dependency property?

    2. How is it possible for my property to still work when I don't have the identifier field in my class directly anymore? According to msdn XAML processing uses the static field identifier, but all evidence indicates that it only needs the correct name as passed to the Register method.

    This won't cause problems from a technical standpoint. The CLR property is actually completely optional when creating a dependency property - the naming (and existance) of a CLR property is entirely a convention - you can leave it out completely and still use the DP without issues.

     

    However, it will cause confusion with users of your class, now and in the future.  There is a convention that a DP will have a corresponding CLR property - without this, usage from code becomes odd, as you have to call SetValue/GetValue directly on the DP.

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    Monday, October 25, 2010 5:07 PM
    Moderator
  • I agree with the convention and reason of point 1. I do see how it would be confusing to name a dependency property 'IsReady' and it's CLR wrapper 'IsFinished'.

    The thing I find more mysterious is point 2, since it contradicts with the behaviour I would expect from reading the documentation.

    Monday, October 25, 2010 5:14 PM
  • It helps if you look at the actual architecture of dependency properties.

     

    They're not actually stored in the object, but rather statically with DependencyObject.  That's why the CLR setter isn't called when you set a DP from binding (and need to have property changed metadata handlers), for example - the value isn't actually tied to the actual object in the object, but rather weakly referenced from a static point.

     

    It's perfectly usable to have DPs that have no CLR prop, or only have a CLR prop getter or setter.  It's just against the standard convention.  Also, breaking the convention will not stop the DP from working, but it may stop some tools from working correctly with your property (especially Blend and the VS designer).  The DP will still work, but some tools may not handle it correctly.

     

    For details, see MSDN.  From this page:

     

    Again, by convention, the name of the wrapper property must be the same as the name chosen and given as first parameter of the Register call that registered the property. If your property does not follow the convention, this does not necessarily disable all possible uses, but you will encounter several notable issues:

    • Certain aspects of styles and templates will not work.

    • Most tools and designers must rely on the naming conventions to properly serialize XAML, or to provide designer environment assistance at a per-property level.

    • The current implementation of the WPF XAML loader bypasses the wrappers entirely, and relies on the naming convention when processing attribute values. For more information, see XAML Loading and Dependency Properties.


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    Monday, October 25, 2010 5:20 PM
    Moderator

  • Thanks for the quick reply!

    I am not talking about the need for a CLR wrapper, I understand the reasons for this.

    I am talking about the dependency property identifier field. The field which you have to suffix with 'Property' according to the documentation .

    In the beforementioned post I don't follow this convention, I don't even have those field identifiers in the class directly, but in a dictionary. Still setting the property and binding to it works!

    From the documentation I would expect this to fail entirely, since it can't call GetValue(...Property) and SetValue(...Property) since they aren't present.

    Hopefully this explanation makes my question a bit clearer, otherwise I'll gladly post additional information.

    Monday, October 25, 2010 5:30 PM
  • Steven,

    The DP system is going to use the terms your factory used.  Since you still have to register the DP, it has the name set appropriately (internally) from the registration call.  However, I would recommend not bypassing convention in this case, even if it works...

    The DP system has rules (by convention) that are clearly documented.  Even if your factory works now, there's no guarantee that it will work with Silverlight, or with WPF 5 later (or even a service pack).  Going against convention is always problematic - sometimes it works, but then will break later (when you don't know why).

    -Reed

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    • Marked as answer by Steven Jeuris Monday, October 25, 2010 6:09 PM
    Monday, October 25, 2010 5:53 PM
    Moderator
  • Thank you for this information, it wasn't entirely clear from the documentation. I could still add the field identifiers to the class by assigning them through the factory. This however would kind of destroy a big part of the purpose for the factory class. :-(
    Monday, October 25, 2010 6:17 PM