Modules initialized after shell / clarification of init sequence

[the-black-wolf]

This issue is also slightly related to issue #1601 - Prism.Wpf: InitializeModules() should be called even if there's no shell

Looking at this piece of code:

Prism/src/Wpf/Prism.Wpf/PrismApplicationBase.cs

Lines 76 to 85 in d8b8a7d

	var shell = CreateShell();
	if (shell != null)
	{
	MvvmHelpers.AutowireViewModel(shell);
	RegionManager.SetRegionManager(shell, _containerExtension.Resolve<IRegionManager>());
	RegionManager.UpdateRegions();
	InitializeShell(shell);
	}
	InitializeModules();

Is there any specific reason why modules are initialized after the shell? Why can't InitializeModules be before the CreateShell and thus have all the type registrations be available inside CreateShell override?

I ask because I have a specific two-prong problem, one is configuration based ACL which affects the layout of the Shell and the other, more problematic, the localization. I could in theory postpone ACL application, but WPF is messed up in the sense that there is no easy way to reload/rebind the entire visual tree based on custom chosen locale. The moment you instantiate visual elements the WPF is set in its culture, and short of very hard to maintain schemes, the only way to change language is to restart the application and change UI and thread cultures BEFORE the first WPF.
Now, the source of the problem is that locale and ACL configuration gets dictated by business logic. One I have in a second module, one whose type registration did not yet happen when the Shell is created/initialized.

I could be missing a bigger picture, but I find this order of init needlessly prohibitive. Especially since main module types do get registered before shell, and so does the registration of modules (both RegisterTypes and ConfigureModuleCatalog are executed before the CreateShell. Issue #1601 addressed the shell-less mode, but it seems to have positioned the module initialization to a wrong point.

[the-black-wolf]

@brianlagunas any comments?

[brianlagunas]

I can assure you the order is correct. I would love to explain all the technical details that goes into that, but I just don't have the time. If this isn't working for your scenario, you can change the order of the bootstrapping process to meet your specific requirements.

[francoisdenis]

I 've just rechecked the lifetime order of method calls in Prism.Wpf (8.1.97):

1. PrismApplication.OnStartup
2. PrismApplication.Initialize
3. PrismApplication.RegisterTypes
4. PrismApplication.ConfigureModuleCatalog
5. PrismApplication.CreateShell
6. PrismApplication.InitializeShell
7. Module.constructor (with params)
8. Module.RegisterTypes
9. Module.OnInitialized

If your App uses a module view, and that view uses a module service in its viewModel constructor,
you will get an exception because the service was not yet registered.

It is problematic.

[the-black-wolf]

I 've just rechecked the lifetime order of method calls in Prism.Wpf (8.1.97):

@francoisdenis Hey man, thanks for responding. But we have actually dumped Wpf entirely and migrated to Avalonia 11 and are now using the community Avalonia Prism. And waiting for Avalonia Prism to merge into the Prism :) It seems to be taking a bit...

#3127

[francoisdenis]

However, I'd be interested to have the opinion of the dev team on that.