michaellperry / Assisticant

MIT License
36 stars 19 forks source link

Assisticant equivalent for default WPF template selector that looks up templates using wrapped object's type #9

Closed robertvazan closed 9 years ago

robertvazan commented 10 years ago
<DataTemplate DataType="{x:Type my:ItemTypeA}">
    ...
</DataTemplate>
<DataTemplate DataType="{x:Type my:ItemTypeB}">
    ...
</DataTemplate>
...
<ListBox ItemsSource="{Binding MixedList}" ItemTemplateSelector="{assisticant:DefaultSelector}" />
michaellperry commented 10 years ago

I implemented this as ViewSelector not too long ago. But I did not implement the markup extension. Could you change the markup extension to use the existing class?

robertvazan commented 9 years ago

Whoops, sorry, I should have looked for existing implementation first. Now that you have put it in the main Assisticant namespace, it would make sense to put both markup extensions in the same namespace as well, so that people don't have to declare multiple Assisticant namespaces in XAML. What do you think?

I think Assisticant is overusing namespaces in general. There's no point in isolating Observable<> and ObservableList<> in separate namespaces. I think the public API (everything except internal/platform wrappers and stuff) should be in one namespace.

michaellperry commented 9 years ago

While I agree that the markup extension should be in the Assisticant namespace for practical reasons, historically I would have put everything UI-centric in Assisticant.XAML. The core namespace was for concepts that were independent of the layer.

That's also the historical reason for Fields and Collections. These things are not core to dependency tracking. They are conveniences for the model layer.

So, yes, go ahead and put the markup extension in Assisticant, but I think Observable and ObservableList are in the right place.

robertvazan commented 9 years ago

I've amended the pull request. It should be fine now.