I am going to start a website, where We want to implement MVP pattern.
One of our page is broken into small user controls so they are used to
edit or display information. But later on we save the whole information
from the main page. Also during the load time, the information is sent
from the main page to the controls. If I design a separate Presenter
for each user control and write logic in that to capture information, there will be many calls to database, whereas if i write that logic in the main presenter and pass data to the user controls, it will just one call. how should it be designed.
Let me explain it.
I have a webform where I capture details like Car make, model, milage, client detail
like name, contact phone number etc. all the controls can be put into one form,
but instead, I created separate controls for each information, like one control for car information, other for customer information. But later on, I want save the whole information from the main page not from the controls. So how will i achieve it using MVP pattern. Should I create separate presenter for each control, then how will I pass information from a user control to the webform, when hit the save button.
Your help will be appritiated.
Regards
Parminder
You should use a Unit of Work design pattern for saving information, where each child control will add queries to save and your main control will SubmitChanges.
Related
I have a custom Calendar control that is showing appointments in a chosen period of time.
I would like to add the ability to create/edit appointments. Appointment edit dialog (fields, save button, cancel button) should open when I click on a day.
Who should be responsible for opening the edit dialog?
Should the control be responsible for opening the dialog and have just SaveCommand and EditedAppointment property.
Or should it just expose commands/events for the user like BeginEditCommand/DayClick event and the user of my control would have to implement the dialog by herself (instead of just implementing Save command)? I think DataGrid works that way
Both solutions will work but which is better?
It's my first custom control in WPF so excuse me for a noob question.
It's impossible to say for definite without understanding where your control fits in the grand scheme of things, but to me editing and adding appointments sound like a part of the application rather than a simple control.
Controls tend to be good at one distinct thing, and reusable in many different scenarios, so need to be flexible. What if the app wanted to skin the appointment edit screen differently? Or display it in a completely different window? Or allow editing of multiple appointments at once?
You could always create another control for editing appointments that they are free to use if you want to make it easy for consumers, and they can plumb it in as they see fit. To be honest though, these things feel like they should be implemented as proper MVVM in the app rather than as custom controls.
I'm very new to WPF. I have to create an WPF app which will do the following:
1) User can change the UI at run time. Controls in each UI are fixed. Suppose two textboxes for numeric value accept and command button to perform multiplication operation and alert the result.
2) Most importantly user can browse the folder of XAML files (UI) and select them / change then at run time. There can be 'n' number of UI users can create and use.
3) I want to use MVVM pattern.
I found this as best example but with doubt. Doubt is that, can user browse user controls and select then, set them? Do they need to be created and added to list before build see this ?
Which is the best way to achieve this task?
If you follow the MVVM pattern, you should create a View (implemented by an User Control) for each UI that your user selects. The Main View will have a ContentControl (or another control type that can host user controls like a HeaderedContentControl) which can host the other Views that the user selects. The view changes will be performed by the associated view model, just like the example you gave.
Trying to answer your question, you should create a menu where the user can select the View to be displayed. The existing views don't need to be added to a list before, because they will already exist in your project. If you want a more detailed example, with code, just update your question with some example you want, like the user can select two views from a menu for instance, and I will add some code .
I would like to write a program that uses several tabs, each showing a data grid. The data of all the grids is stored in a single data source. Each tab should look identical except for the number of colums/rows and the values of course.
So I am now trying to put the grid view into a user control and create a .dll. If a tab is added I put the user control into it - this works already. The grid works in virtual mode and if a new tab/grid is created it calls the event to load the data into the grid.
Now I have the problem that the grid and the LoadData event are in the user control while the data source is in my main program. So in the user control the data source is undefined. I thought that this would be ok because you do not run the user control alone and once it is used in the main program the data source should be available to the LoadData event. However, it does not seems to be possible to generate the .dll while the data source is unknown.
On the other hand I do not want to put the data source into the user control because then it is dublicated every time a new tab is created.
I hope you can give me a hint what is the best way to implement it.
thank you very much!
I don't know what answer (how detailed) you expect, but I think this is a very good example to:
reuse one control
use MVVM architecture pattern
I would try to seperate class which would execute logic responsible for creating ViewModel. Control (grid in your purpose) would be always binded to this ViewModel, and this Control would be reuse in different Views. Depend on where it would be placed you can add some additional features if it is necessary (Decorator design pattern). If you expected more detailed (not conceptual) solution than sorry.
I have a winforms tab control which has several tab pages. Within each tab page controls (textboxes, radio buttons, etc...) are group into groupboxes. These group boxes are arranged from top to bottom but in some occassions some groupboxes needs to be visible and other ones to be hidden. Also control within each group box sometimes (depending on the scenario) needs to be visible and sometimes hidden. So I would like to know if someone knows a good approach to do this, maybe some kind of pattern if any. Also it would be good to implement a generic solution to do this. Could any expert in GUI guide me in the right direction to do this?
Using C# and dot NET Framework 4.0, WinForms. This is a desktop application, not Web-based.
You can define the scenarios in a class then add another class that will manage the layout by reading the scenario and laying the elements based on the scenario. I have not provided details because it varies on how specific you want to be and what behavior you want to achieve. It is better to put the Widgets inside a User Control and let that user control communicate with the layout manager.You can use the Mediator pattern or variation of it to coordinate between the widgets. Hope this helps.
I usually try to group related controls into UserControls (even if this means doubling up on some controls) and adding them to or removing them from the form as needed. An example of this could be payment methods - when the user selects a specific payment method (Credit Card, Cash, Cheque, etc) a UserControl with the correct elements is displayed within a panel on the form.
A good pattern to use when managing this sort of set up is Model-View-Presenter, in the example, all the UserControls would probably implement an IPaymentMethod view interface and provide a way to update the corresponding models.
I'm trying to modify a C# WinForms application that uses multiple forms. At startup, a login window will be shown. If the user logs in with a correct user name and password combo a form with three different tabs will be shown as a sort of administrators view. If no password or user name is supplied, a much simplified GUI will be shown. It will basically consist of two buttons that in turn shows these two forms depending on which button is pressed:
Button 1: Give the user access to a form consisting of a number of textboxes where the user can input information that will be saved to a database. Once the DB-operation has been executed successfully, the first form with the two buttons will be displayed again.
Button 2: A form is shown where the user can input a code that will be written to DB. Once the DB operation is concluded, the user will automatically be taken back to the original form with the two buttons.
Both forms will also have a back button to take the user back to the first form. I have a lot of logic in place, but I am unsure of how to best handle all the forms involved. Where should I instantiate the first (login) form? Once the login validation is done there are two possible ways to go. Either show the tabbed admin form (if user name and password is correct) or the simplified user form with two large buttons. It should also be possible to logout from the admin form so that the simplified GUI is shown instead.
I hope I am making sense here. I just need a good way to handle all the forms and navigation between them. Currently, there aren't really any need for transporting data between them, but it might be an issue in the future so a solution that takes this into account would be excellent.
I'm thinking that what is needed is really a class that handles the displaying and disposing of the forms right from the start, but I'm not quite sure where I should put the instantiation of this handling class.
I just did something similar. I had a set of forms to manage as "pages" as the spec called them. I also had strict page flow that was a bit more complicated than yours. I'll talk you through that.
I designed each "page" of interaction as a UserControl and created an "OuterForm" and a "Controller". The controller had a Navigate(string pageName) method and the outer form contained a panel and had a Display(Control page) method which cleared the children on a panel and added the replacement.
I used Spring.NET to configure the controller and the form and used setter injection to create a two way link between the two. That meant my main method could ask Spring for the form and just display it using Application.Run(form);
I created a convenience method to access the controller from event handlers and would do e.g. Controller.Instance.Navigate(chosenPage); The controller also used Spring.NET to load the correct UserControl for chosenPage and then called on the main form to Display() the instance it loaded. There as no Spring.NET code in any user control, and no new keywords either ;-)
The advantage for me in using Spring.NET is that I had one form class that just monitored some business logic and displayed a progress indication. I was able to implement that once and configure many instances of that form injected with different business logic that it would monitor. Also, I needed to stub out interfaces to domain specific pieces of hardware and web services. Eventually I moved page flow into the configuration as well.
Form management can be a tricky issue. There are some different ways to go:
Just have the forms float around on the screen. Let some static class hold references to the different forms and expose methods to activate them.
Implement the forms as UserControls instead, put them onto the same form, and show and hide the controls as appropriate (this can also be achieved by loading the forms, stripping form borders and such and setting their parent to a panel or something similar; this will almost make them behave like user controls, but only almost)
There are many other methods, of course ;o)
When it comes to managing the login form, I would do that in the Main method; show the login form, check the credentials and then instantiate the UI you want to show and pass that to the Application.Run method.
Have you considered using a Composite UI framework? In your case, you could use WinForms with CAB.
One of the big advantages is the support for role based authentication. An authenticated session could match one role, a non-authenticated session could match another role. Thus you can display different screens depending on the role of the user.
Another advantage is the answer to the problem of who is responsible for instantiating screens. This is managed by the controller, and actions on the screens (eg button click) can send events to this controller.
Last but not least, there are some good samples available and there is definately support for more advanced scenarios.