I'm writing a WPF application while mostly adhering to the MVVM design pattern. The application has various educational modules broken up into different categories to be accomplished by the user. The modules are organized into a hierarchical menu. My ViewModel has a class called MenuPageViewModel which exposes the information needed to render a MenuNode. Naturally, the terminal elements in the menu tree have content that I'd like to display to the user. This content can be one of many different types of modules. Currently, when the user selects a module in the menu, I can't see any way around using a large conditional block to determine what type of ViewModel I'd like to return to be displayed based on the type of the MenuItem's Content Property. For example...
if (CurrentlySelectedMenuItem.Content is Lesson)
return new LessonViewModel(CurrentlySelectedMenuItem.Content as Lesson);
if (CurrentlySelectedMenuItem.Content is SkillsCheck)
return new SkillsCheckViewModel(CurrentlySelectedMenuItem.Content as SkillsCheck);
Can someone give me a hint to a more elegant and maintainable approach? Right now, if I add a new module type, I have to remember to update this conditional block, and that just sort of annoys me.
Thanks.
If you are using Unity/Prism then using the container to resolve the object would be my first preference.
_container.Resolve(Type.GetType(strObjectType)) as BaseViewModel;
where strObjectType is a string with the type of class you want to create (eg "LessionViewModel" )
if you are not using Unity, then reflection works
Activator.CreateInstance(strObjectType) as BaseViewModel;
with both solutions you need to have the string with the class type on your menuItem.
A third option is to have a factory, but it would probably end up having a conditional situation within it or will contain the code i just listed.
Related
I would like to know how you are Design your Qooxdoo Code.
I don't get the right Architecture which I am satisfied with.
It is hard to encapsulate the View with logic like services.
I hope someone can give me a hint to a Pattern or something to find a good solution.
One of Qooxdoo's greatest features is a strong OO class system, so really the pattern that you use is up to you - MVC, MVVC, etc are all possible because Qooxdoo's OO system provides you the tools to implement your preferred pattern(s).
One pattern that I find very useful, especially in creating larger apps, is to define custom widgets for editing models; for example, if you have models (aka "Business Objects" etc) for Customer, Invoice, InvoiceLine, and Address having a widget for CustomerEditor, InvoiceEditor, InvoiceLineEditor, etc is really useful firstly because it encapsulates the code, but also because it supports binding.
Binding is a very powerful feature of Qooxdoo - to see why, let's assume for a moment that each one of your Editor widgets has a property called value which is the thing being edited.
In simple binding, your editor can bind properties of the model to the widgets which display and edit those properties, eg CustomerEditor bind value.firstName and value.lastName to a couple of qx.ui.form.TextField and automatically changes to the customer's firstName or lastName will be updated in the two TextField's. Binding can work the other way around too, so that changes to the TextField are copied back into the model.
There is a controller class called qx.data.controller.Form that can simplify making this happen, and optionally incorporate validation of user values and user feedback too.
If you have separate Editor widgets, you can also bind to them - for example, Customer could bind value.address to an instance of AddressEditor, and InvoiceEditor could bind the currently selected InvoiceLine to InvoiceLineEditor etc
I'm using Ext Js 4.1.1.
In many of the Ext JS widgets I am using, I am required to reuse data. For example, the items collection for buttongroup in top toolbar may be repeated in menu bar on the left side. For manageability, I should be able to have the array for items collection defined in a separate file (which could potentially follow the class naming convention for auto loading).
The approach I tried is that I am creating a class that has statics. Each static function returns an array that can be assigned to items collection of the widget. This works but I believe that using a class is an overkill if I can just use an array. Any suggestions?
Not sure if it will be useful to create separate objects for storing configuration for toolbars, buttons groups and etc. In the context of the extjs in almost all cases you need not only manage configuration but also behavior of a component.
The best way for me here - creation of generic/basic predefined classes, where you can state not only configuration but work around the behavior, add you'r custom events and process any unexpected results. After it you can easily reuse and extend it easily.
For instance you have a menu or a toolbar with 3 items A, B, C. For sure you need to know wherever you use it what was clicked (for instance) A, B or C. Creating a class and manages required events you can fire you own events which will tell you what was clicked and it is much easier to use in any context where this component will be used. Add post and pre processing, template methods and etc...
Creating a big file just with configuration is not readable and not extendable, will be a case whre you will need to add functionality and behavior to all such generic components and it will be not easier to do with just arrays or simple configs. Separating even just simple general components having just simple configuration (in the beginning) will bring more expressive in the code structure and readability and in the later time gives you the power to manage it.
Pure configurations can just keep the code accurateness and re-usability but what about behavior for in almost cases you need to control..
The design, maintainability and extensibility are very important points in every big web-applications and in context of extjs 4.
Hi I am using an interface IFooNode, which is part of a tree.
I wanted to display this tree in a TreeView using a HierarchicalDataTemplate.
This however does not work due to the interface.
I see two ways around that neither are what I would call "nice"
Find out what type really implements IFooNode (let's call it FooNode...), then find the assembly defining FooNode, add a Reference to that assembly and create a HierarchicalDataTemplate for FooNode (hoping the Implementating class never changes...)
Write a class MyCoolIFooNodeWrapperForWpf that wraps IFooNode, do not bind to the tree, but fill a list of MyCoolIFooNodeWrapperForWpf from the tree root and create a HierarchicalDataTemplate for MyCoolIFooNodeWrapperForWpf.
Can I somehow always apply a HierarchicalDataTemplate, no matter what type the data is (This I think would be the lesser evil...)
Any other Ideas?
You can use ItemTemplateSelector. In the selector's code you can check which interface your data object implements, and select the appropriate DataTemplate/HeirarchicalDataTemplate for this item.
The selector can both be applied to the container itself (ItemsControl.ItemTemplateSelector) and to your hierarchical data template (HeirarchicalDataTemplate.ItemTemplateSelector).
I think this is the lesser evil.
If you're not selecting from among multiple templates, you don't need to specify a data type on the template. If all of the objects in your tree implement your interface, just stick in a template using properties of that interface and you're good to go. You don't need to do anything in the template to make it specific to that interface.
If, for some reason, you need to do template selection based on what interface an object supports, you need to implement a template selector, and deal with the many-to-one problem that prevents WPF's built-in template selection mechanism from using interfaces in the first place. (That is, if you have a template for IFoo and one for IBar, what template do you use for an object that supports IFoo and IBar?)
I am starting my first foray into the world of Prism v4/MVVM with MEF & WPF. I have sucessfully built a shell and, using MEF, I am able to discover and initialise modules. I am however unsure as to the correct way to provide navigation to the views exposed by these modules.
For example, let's say that one of the modules exposes three views and I want to display navigation to these views on a menu control. So far, I have sucessfully exposed a view based upon a MenuItem and this MenuItem contains child MenuItem controls thus providing a command heirarchy that can be used. Great.
Thing is, this feels wrong. I am now stating within my module that navigation (and therefore the shell) MUST support the use of menu's. What if I wanted to change to using a ToolBar or even a Ribbon. I would then have to change all of my modules to expose the corresponding control types for the shell.
I have looked around and there is mention on some sites of using a "Service" to provide navigation, whereby during the initialisation of the module, navigation options are added to the service which in turn is used by the shell to display this navigation in whatever format it wants (ToolBar, TreeView, Ribbon, MenuItem etc.) - but I cannot find any examples of actually doing this.
To put all of this into perspective, I am eventually looking to be able to select views from a menu and/or other navigation control (probably a Ribbon) and then open those views on demand within a TabControl. I have already gotten as far as being able to create the views in the TabControl at module initialisation time, now I need the next step.
What I need to know is this: what would be the correct way to expose navigation options in such a way as not the insist on support of a specific control by the shell, and if a service is the way to go then how would one put this together within the Prism/MVVM patterns.
Thanks in advance for any insight you can offer.
I suppose you have a main module containing common interfaces.
You could create a simple interface like
public interface IMenuService {
void AddItem(string name, Action action);
IEnumerable<MenuItemViewModel> GetItems { get; }
}
Create 1 implementation and a single instance.
public class MenuService : IMenuService {
private readonly IList<MenuItemViewModel> items = new List<MenuItemViewModel>();
void AddItem(string name, Action action) {
items.Add(new MenuItemViewModel {
Name = name,
Action = action
});
}
IEnumerable<MenuItemViewModel> GetItems {
get { return list.AsEnumerable(); }
}
}
Within your modules, use MEF to resolve this instance and call AddItem() to register your views.
The Action property is a simple delegate to activate a view or do anything else.
Then in your shell or any view, you just need to call the GetItems property to populate your menu.
Having thought about this some more, I have come to the following conclusion that I feel affects the way that I need to deal with this...
The modules need to be partially aware of the shell layout anyway - that is, the shell exposes a number of regions and the modules need to be aware of those regions (by name as well as what is expected to be shown) in order to populate them correctly when functionality is requested (either by means of registering a view within a region or as the reaction to a user action).
Because of this, the modules need to be designed to interact with the shell to place content into the named regions and as such, I see no reason why the modules should not expose whatever type of navigation the shell supports.
Therefore, my modules (currently) expose a "RibbonView" (a RibbonTab) with the necessary icons, buttons and commands etc to expose the functionality of the module. Each "RibbonView" is registered with the "RibbonRegion" of the shell, along with hints for ordering, and this is then rendered within the shell.
If in the future I choose to update my shell to use the latest+greatest navigation control (whatever that may be in x years time) then I simply need to update each of the modules to expose the necessary items to integrate with that new navigation and, because I am loading into a new shell, I can then update my view registration accordingly.
I just hope that I am not breaking any of the principles of the composite application in doing this, but that said I have never yet found a pattern that can actually be implemented in a real scenario without some "interpretation".
I would be interested to hear if anybody has any opinions on this.
I've encountered the same situation, and I think the solution lies in differentiating between interface and implementation. For example, you can design a view in a module that performs a given function. That's all it does. As soon as you use or consume this in a specific context you've crossed over into implementation. Now, ideally the view is unaware of how it's being implemented, and certainly would have no knowledge of named Regions in the Shell. So, seating views into Regions within a module is a no-no.
To get around this, I've opted to delegate this responsibility to a third-party component, a LayoutManager. The LayoutManager sits between the Shell and Module and defines "what goes where". It is a specific implementation, and really defines the implementation. Both the Shell and the Module view remain generic.
Have a look at: http://rgramann.blogspot.com/2009/08/layout-manager-for-prism-v2.html
Which may give you some ideas around this problem.
Hope it helps.
This article uses an abstraction (IMenuItem) to represent the ViewModels for your menu choices. How you actually render these imported objects is really up to the host application. The example uses a WPF menu, but you could certainly render it any way you wanted because IMenuItem is abstract enough.
If you changed IMenuItem to INavigationItem, you've got what you want.
In that article, when the particular navigation item gets notified that it's been "run", then it usually instantiates a ViewModel for a document or "pad", and passes that to the ILayoutManager service. It has a pluggable architecture, so you can swap out the LayoutManager service for a different layout engine (the default one is a wrapper around AvalonDock).
Say I have a WinForm CRUD(like) application. I want to follow best practices on this so I try and make it follow OOP and a n-Tiered design.
Unfortunately I am familar with the words but not the practice of them. So lets go with the following example: My CaseNote program. I have a tabbed application where you go to the search tab to find a member and then one of the options is to go to the CaseNote tab to create a new case note, look at existing CaseNotes, or create a follow up CaseNote to a Parent Note. All of this is for the member you selected from the search tab.
So if I am creating objects and passing them around to be used by different forms where should I be instantiating them? I had thought I would have 3 layers; UI, Object, DAL. Where I fall flat is where I instance tho objects. I can't instance them in the object layer, can I? Also, if I instance them on the form how do I pass them from form to form in a quite large app?
CaseNotes Screen Shot
If you want to look at some more words around this problem you want to look at MVP and MVC. (These stand for Model View Controller and Model View Presenter). Some people will shoot me down for saying this but they are quite similar in concept.
The aim of MVP and MVC is to allow you to design your application logic without even having to think about your application apperance. It also allows you to define your user interactions without implementing an actual GUI. Esentially your model is your application logic, your data, your classes which actually do stuff like talk to your database. Your presenter or controller is what interacts with your model and what controls your user interface and reacts to user operations on the interface. Finally your View is your winforms design or your web page.
I'm sure you will be able to find plenty of material on the web about this but to give you some concrete help with this problem should serve to inform and illustrate your reading.
The first thing you need to do is start creating your objects that represent your data. So you will have a CaseNote object which is contains the casenote data. You will have a case note data container of some sort such as a case note database. You can define the logical operations and properties of these as if they where real items.
Then you would move on to define your presenter or controller which will define the operations that you want to support from the GUI. At the same time you should define an Interface that will define for the presenter/controller what operations is can perform on the GUI. So for instance your presenter may expose a method called SearchForCaseNote which takes a string parameter. Your view Interface will expose a method called DisplayCaseNote. When a user clicks on the search button the view will pass through the command to the presenter which will then call the model to get the data. The presenter may format the data at this point, i.e. convert DateTime object to a string and then pass the data back to the view through the interface define method called DisplayCaseNote.
You don't have to use the View interface, you could call into the view directly, but having the interface means you can have many different view implementations.
One last thing i need to mention is where you create these different parts of your application. My view is everything thing should fall out from the presenter/controller. So when you application starts it creates the presenter/controller object which then create and displays your view passing itself as a variable to the view. The presenter/controller can then either create the initial models by loading them from disk or ideally discover them through a dependency injection container like unity. In fact using unity to discover the view implementation is probably a better idea again as it gives you true seperation between view and presenter/controller. When you come to move to another view, (i.e. open another window), your presenter/controller should expose a method such as DisplayDetailPage which the view calls when a button is clicked. This would create the presenter/controller for the next view which would in turn create the view and get a reference to the model.
Hope this helps.
I think you should use the RocketFramework