I am new to CAB framework. After going through the sample GPS application I understood how a single module is loaded and its view is displayed.
I have a project in which I have 3 forms. Should I create a single module with three different Views for this or should I create three different modules for this.
If I create three views, how do i Switch between these views. And if I am creating three different Modules, how do i switch between these modules.
thanks.
If you will always use these three forms together, put them in the same module. If you will need only one or two of these forms at a given time, put them in separate modules, so you can load only the forms you need on demand.
I don't understand what you exactly mean by "switch between modules". If you refer to how you select which modules to load at the application start, you do it by overriding the GetModuleCatalog method in the bootstrapper and creating a module catalog inside the overrided method. If you mean how to load modules dinamically at any point in the application, you can do that by using the LoadModule method in the container's IModuleManager object.
Related
I am implementing a view model that is shared by applications on multiple platforms. I am using MvvmCross v3 that has its own MvxEventToCommand class, but I believe the challenge is the same for other frameworks like MVVM Light. As long as the event is used without parameters, the implementation is straightworward, and this is the case for simple interactions like tapping the control.
But when the command needs to handle event arguments things become more complicated. For example, the view model needs to act on certain scroll bar changes (and load more items in the associated list view). Here is the example of XAML:
<cmd:EventToCommand
Command="{Binding ScrollChanged}"
CommandParameter="{Binding EventArgs}" />
(MvvmCross uses MvxEventToCommand, but the principle is the same).
Then in my model I can have the following command handler:
public ICommand ScrollChanged
{
get
{
return new RelayCommand<ScrollChangedEventArgs>(e =>
{
MessageBox.Show("Change!");
});
}
}
(MvxCommand in MvvmCross).
The problem is that ScrollChangedEventArgs is platform specific and this code simply will not compile in a portable class library. This is a general problem with any command that needs not only a push when an event was fired but requires more specific event details. Moving this code in platform-specific part is silly because it more or less kills the concept of portable view models and code-behind-free views. I tried to search for projects that share view models between different platforms, but they all use simple events like "Tap" with no attached event details.
UPDATE 1 I agree with Stuart's remark that view models should only deal with higher level abstractions, so I will rephrase the original concern: how to map results of low-level interactions to a platform-neutral event that triggers a business logic command? Consider the example above: the business logic command is "load more items in a list", i.e. we deal with a list virtualization where a limited number of items from a large collection are loaded initially, and scrolling down to a bottom of a list should cause additional items to be loaded.
WinRT can take care of list virtualization by using observable collections that support ISupportIncrementalLoading interface. The runtime detects this capability and automatically requests extra items from a respective service when the user scrolls down the list. On other platforms this feature should be implemented manually and I can't find any other way than reacting on ScrollViewer ScrollChanged event. I can see then two further options:
Place OnScrollChanged handler in a code-behind file and call the portable view model higher level event (such as "OnItemsRequested");
Avoid code-behind stuff and struggle to wire the ScrollChanged event directly to a view model, then we will need to remap the platform-specific event first.
As long as there is no support for second option, putting event handler in code-behind file is OK as long as it is done for the sole purpose of event mapping. But I would like to investigate what can be done using the second option. MvvmCross has MapCommandParameter class which seems to be able to help, so I wonder if I should exploit that one.
UPDATE 2 I tried MapCommandParameter approach, and it worked allowing me to insert a platform-specific adapter that would map low-level events to view model-specific commands. So the second option worked without any struggle. Stuart also suggested listview-subclassing so there is no need to care about scrolling events. I plan to play with it later.
I agree that viewmodel commands should normally be expressed in terms of viewmodel concepts - so it would be 'strange' to send the viewmodel a command about the scrollbar value changing, but it might be ok to send the viewmodel a command about the user selecting certain list elements to be visible (which she does via scrolling)
One example where I've done this type of thing previously is in list selection.
I originally did this across multiple platforms using a cross-platform eventargs object -
https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross/Commands/MvxSimpleSelectionChangedEventArgs.cs
this was then used on WindowsPhone (for example) via an EventToCommand class like https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.WindowsPhone/Commands/MvxSelectionChangedEventToCommand.cs
However... I have to admit that this code hasn't been used much... For list selection we have instead mainly used selecteditem binding, and there simply haven't been any apps that have needed more complex parameterized commands (so far) - you might even need to go back to very old v1 mvvmcross code to find any samples that use it.
Is it possible to use a custom view file in a module (eg. user) in order to keep the module (3rd party) intact?
Somehow extend the module, with a views folder that holds my custom views.
The path to the module theme views should be
/{{your_app_name}}/themes/{{theme_name}}/views/user/
Copy all of the module views from the folder
/{{your_app_name}}/protected/modules/user/views
to the mentioned above folder and that will do the job. After that you could customize the views as you like.
Copy user module view files to <app>/themes/<current_theme>/views/user/. More general, customize module views using the folowing "formula": <app>/themes/<current_tehem>/views/<modules_name>/<controller_name>/<view_file_to_customize>.php
Use a theme. For a module named "user" and a view path of "profile/edit", create "/themes/flashy/user/views/profile/edit.php". You can also define a new layout in "/themes/flashy/layouts/column2.php". Then add to your configuration file in "protected/config":
return array(
// many settings...
'theme' => 'flashy',
For the module "user" you pointed out, unfortunately its controllers use absolute paths for their layouts (e.g. "//layouts/columns2") so AFAIK you can't define distinct layouts for the application and this module.
See also the official guide chapter on theming with Yii.
I disagree that in many help forums of the Internet, when someone asks abot theming a module, everyone suggests a path alias to the themes folder. I think this is wrong, because it implies modules to be splitted, and modules are supposed to be a black-box that can be used across projects. The advice given in such forums would only be valid if a theme is shared among several modules. If someone wants to "package" a theme inside a module, she can:
-add an init function to the controller of the module
-inside that init, use the class attribute layout and a path alias, like this, supose a module whose id is "Sample":
then you add, to SampleCOntroller.php:
public function init() {
//BELOW: it will use the layouts/main.php inside the module.
$this->layouts = "sample.views.layouts.main";
}
I have a PRISM desktop app which loads modules from a directory with the help of the DirectoryModuleCatalog.
Everything is fine, except that I cannot find a way to get the instance of a loaded module.
IModuleManager and IModuleCatalog don't have a method like getInstance(ModuleInfo) or similar.
See
moduleManager.LoadModule(moduleInfo.ModuleName);
This line loads the module properly(moduleManager is of type IModuleManager), but what do I have to do next to get the actual instance of this module?
The modules are loaded on demand of the user, so I cannot register all modules at startup within the bootstrapper.
If by Module instance you mean the class that implement IModule, then you must explicitly register the instance into the container to be able to get it.
Although the aforementioned will work, you should not take that approach at all. The idea is that the module classes are specific to a particular module and should only be used for module initialization purposes.
I would place each module's Start method in a separate component (IStartable), register each component in the container with a different Id and resolve/import an IEnumerable to get all instances that have the start method.
Hope this helps
I have a program that is getting pretty big and it is a pain to find everything through all the functions and classes.
I am trying to break it up into other files based on their method.
Some of these functions have calls to others in the main class. I changed most my functions from private to public to access this. I had problems calling certain code created windows so importing mainwindow helped that.
My last problem is editing the mainwindow ui from one of the module files. I want to make sure im on the right page before i continue breaking it up. My only guess is that anything they updates the ui should be left on the main class.
Thanks
The only code in your form class should be code that talks to other classes and updates the UI based on data from other classes.
Depending on your application, the form class might handle change events from other classes to update the UI or pass user input to other classes in Change or Click events.
A couple options:
Use callbacks into the your main window.
Create events for when you need the form updated. Your program logic raises the events, and your main window class can consume them.
I am learning Prism, and I have a question on the best approach for the main Shell.
Assuming the Shell has 2 regions: Toolbar, Main.
The toolbar has 3 main buttons that each represent a different On Demand Load Module.
Each of these modules currently register themselves as fitting in the Main Region.
When I click one of the buttons I want to do the following:
Notify any active view that its switching, with an option to cancel if there is a pending action still required.
This might cascade to child views.
If the action isn't cancelled then load the on demand module if it has not yet been loaded, else activate it within the region.
Should these three modules all fit in the same Region or should my shell have 3 regions defined within content presenters?
One of the areas I got stuck on was that when you register a view from the Module Initialize, it doesn't get added with a strongly typed name, so when I tried to determine if my view was already added to the region with GetView(viewname) it always returns null, so I end up adding another view to the region.
Having all views register in the same region (say "MenuRegion") is a good approach. As for checking for dirty views you might find this blog post from Brian Noyes useful:
Supporting Graceful Shutdown and
Saving on Close From a WPF Prism App
I hope this helps.
Thanks,
Damian