Fixes #3522. Adds IDesignable: Ability for Views to load design-time/demo data

[tig]

Replaced by #3575

I don't know what rebase error I keep making, but I continue to eff my branches up. Arrrrg.

[BDisp]

LGTM. But I would like @tznind take a look on this. Thanks.

[tznind]

So this function updates the state of the View to an 'example' state?

This makes sense and means some code can come out of TGD ViewFactory.

Makes sense for the view tester too.

I like it!

[dodexahedron]

Neat. I'll take a look at this one either later tonight or some time tomorrow.

[dodexahedron]

Getting to this in a few minutes, once I go through the last few items at the top of my inbox.

[dodexahedron]

Looks pretty good to me.

But I made a couple of suggestions with code for some design-time and run-time improvements.

[tig]

Regarding other possible things to add to this interface: Not gonna do it until actually needed. First rule of API design is to not expose something publicly until there are at least 3 known use cases.

[tig]

Ok, how's this?

[dodexahedron]

I think your original naming was better. Enable is kinda confusing since that's now a member of the View. I wouldn't expect SomeView.Enable() to load demo data.

[dodexahedron]

Regarding other possible things to add to this interface: Not gonna do it until actually needed. First rule of API design is to not expose something publicly until there are at least 3 known use cases.

Yep, agree there.

In any case, pretty much everything needed is already in the View class and derivatives anyway. Maybe we should take a refinement pass in beta or something to go through and annotate things around the library with appropriate/useful attributes like that?

[dodexahedron]

Almost there.

I think good to go with these additional little tweaks.

[tig]

I think your original naming was better. Enable is kinda confusing since that's now a member of the View. I wouldn't expect SomeView.Enable() to load demo data.

Now EnableForDesign

[dodexahedron]

I don't really have a lot to add beyond what we talked about in the issue already.

All I put in here was a suggestion/remindr about CombinatorialData for XUnit. Unimportant.

[dodexahedron]

How about, instead of all these inlines:

    [Theory]
    [CombinatorialData]
    [InlineData (-1, 0)]
    [InlineData (9, 0)]
    [AutoInitShutdown]
    public void MouseClick_Fires_Accept ([CombinatorialRange (0, 8)] int x, [CombinatorialValues (1)] int expectedAccept)

Or similar.

InlineData can still be used for one-off cases, as shown, and are explicit cases beyond the "combinatorial" cases, but do get de-duplicated if you accidentally specify any dupes.

Don't bother if you don't want to, though.

There are other things about the tests that are more important, but that's so far down my list right now. 😅