search

Caliburn-Micro / Caliburn.Micro

A small, yet powerful framework, designed for building applications across all XAML platforms. Its strong support for MV* patterns will enable you to build your solution quickly, without the need to sacrifice code quality or testability.
http://caliburnmicro.com/
MIT License
2.8k stars 778 forks source link

[Question] Why activating is not allowed when conductor is not active? #774

Open sherman89 opened 3 years ago

sherman89 commented 3 years ago

Hi CM team!

First of all thank you for the great work on this framework, I've been reading the source code and thinking about its design and it really is well thought out and powerful. For example the cascading of close events down the ViewModel hierarchy is a really useful and powerful feature.

I was wondering though, what is the reasoning behind not allowing activation when parent is not active? I can see how it makes sense, but is there any practical benefit from that restriction? Also, why not include OnActivated method that can be overloaded, even though there is an event for it?

Also, is there any good reason why closing is lumped with deactivation (as a bool parameter) rather than having an explicit OnClosingAsync method?

If there's any other design decisions in CM that you think are not good, I'd love to hear your opinion about them.

Thanks a lot! 🙏

snalesso commented 2 years ago

I don't know the real answer for any of them, but I can try to reply.

Closed event & OnActivated I think it was a "2 birds with 1 stone", I agree it's way more flexible to separate the 2, but maybe when you want to get the job done fast you leave details for a later moment, that maybe was forgotten when it was time to add a "virtual" keyword before "OnActivated` (if by "overloadable" you meant "overridable").

Activation flow Here I would like to hear from the maintainers.
AFAIK the Conductor-Screen architecture aims to control the view activation status of all the UI tree children inside a view. Since Window has Activated/Deactivated events (and relative IsActive property) i'ts easy to handle those events by hooking the ViewModel's handler to the view's events, but if your view is not a Window, and it doesn't have those events, you need some other way to make the view-model know.
If this is the purpose, I wonder how this structure should be set to handle a child Window's lifetime. Maybe we're supposed to create a custom implementation of a Conductor, but since there's an IViewManager implementation, maybe this scenario should be natively supported.