WF 4.0 -- Designer Type Visibility

WF 4.0 -- Designer Type Visibility

  • Comments 3

One of the exercises I'm going through now is scrubbing our API and taking a hard look at types marked as public and trying to decide "does it really need to be public."  While on first blush, you can

What I'd love to get from folks are answers to the following questions:

  • Were there designer types in 3.0/3.5 that were not public that caused you problems?
    • If so, why?  What and how did you want to use that type?
  • Were there scenarios where you found our decisions on type visibility odd, inconsistent or painful?  Let me know what those were.

 

Looking forward to your thoughts!

  • 1) StateMachineDesigner. I want to override some methods and not recreate all. I had to use FreeformActivityDesigner. I´m hosting the designer into my application and created state machine activities with more usability to create workflows. My final user can create workflows.

    2) Why not public classes?

  • Just last week I needed to use the private InvokeWorkflowDesigner to display a custom InvokeWorkflowActivity on a State Machine design surface.  I found that it was applied to the InvokeWorkflowActivity at runtime in both a tricky and inconsistent way.

  • @rafaelleonhardt,

    Why not public classes?

    > We have a pretty high cost for any public type that we ship (we have to document it, clear it through a more rigorous set of API reviews, etc), as well as a high longer term cost, we don't want to make something public if we think we will change or improve it in the future.  Also, if we don't think we've got quite the right design, but we have something that works for the release, we would think about making it internal.

    The problem with a complex designer like StateMachineDesigner is that you can't insure that there isn't a tight coupling to the underlying activity type.  This is why StateMachineDesigner (and related types are sealed)

    @philipwolfe,  I'd love to hear more about this.

Page 1 of 1 (3 items)