Closed GeertvanHorrik closed 7 years ago
So there are a few ways to do this:
Thank you Geert, you wrote: "There are 2 ways of modularity: 1) Catel.Extensions.Prism 2)Orc.Extensibility Both sit on top of Catel, and if we had to re-implement, Catel.Extensions.Prism would probably be Orc.Prism. But... since we never use the region manager in prism and wanted to be able to customize the plugin search functionality, we decided to implement our own (being in control is a big plus for us). We prefer Orc.Extensibility, but that's because we don't use the other stuff in Prism and it allows us to be in full control about future updates. Orchestra itself does not support modularity. You can implement it either via Prism, Extensibility or something your write yourself (but wouldn't recommend that, Orc.Extensibility does a lot of the heavy lifting (including the reflection-only analyzing of the extensions))."
Thats great.. It would be nice if a sample shows the right way. I know Money and Time. ! I just need a Demo how to do this: I have a Orchestra appplication. The shell has some backstage commands like: Open, New, Save SaveAs..Close..Info.. etc. I have four kind of projects which uses these commands and have to run in the "one" Shell. I dont want to implement 4 applications. It will be a configuration software for a lot of similar configuration modules. I want to have four "New"'s ... for every kind of project. These commands are common for all modules.. But: ProjectA has different Content in MainView and a different Ribbon control as the other 3 projects... The shell should have a ContentControl region, a tab region, and then a view needs to be injected into a hosted tab view. (maybe has Allan a sample to this?) I have not tried it the ModularityWithCatel.Desktop sample yet. Thanks!
We recommend to use these libraries:
We don't have the resources at the moment to create lots of examples (we are working on Catel v5 at the moment, which is more important to us). Of course we are also available for consultancy so we can help you set up the shell (but we don't do this for free). We are able to set up a whole shell with interactions in just a few days to give you a great headstart.
Our solution relied on a LOT of custom changes we made to both Prism and Orchestra and whilst Greet recommends these plugins we could never get them working well enough in a production environment. However I can recommend looking into MEF instead of Prism and create your own "add-in" that your application understands and can inject the parts into the various parts of your application. Greet (and co) have created an excellent resource and take you a fair way, but it is up to you to tailor the solution to fit your needs. I'm sorry but I can't share our solution with you as they are included in our propitiatory solution, and doubt that it would fit your requirements as it wasn't meant to be for generic consumption.
Thank you all... Orchestra is a composable shell and WPF framework built on top of Catel...
Correct, it's composable because the shell has different regions (e.g. a ribbon, actual content and a statusbar) that you can compose. Composable doens't necessarily mean that it can load extensions at runtime (that's why we built Orc.Extensibility which takes care of plugin functionality).
Thank you Geert ! This issue could be closed...
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Initially written in #49 by @Aitania
Hallo Allan, "...we started with the Prism modularity example in the catel/orchestra repository, and then used a bare bones version of the shell to attempt to load the module dlls into various regions in the shell. All has to be loosely coupled as the shell doesn't know about the modules and vice versa. That was our first issue, because the modularity example isn't loosely coupled. the shell has references to modules. The shell should have a ContentControl region, a tab region, and then a view needs to be injected into a hosted tab view. This is the general gist of what we were trying to achieve, all whilst maintaining viewmodel first and the instantiation thought catel's mvvm core, not prism's activator.createinstance.! have you a sample how to do this from ribbon backstage commands?