Recipe Tracker: Upload 4
https://docs.google.com/leaf?id=0B7jSfuxfxwTLNWJhMjAxNmUtMjc2NS00YmYwLWFjNmYtZjAxZmM1MjM5MWNi&hl=en
Well, there is the link for the fourth installment. I jumped the gun a bit. I didn't clean up the problems I was having with my mappings and dove straight into coding the WPF portion of the application. Right now there is a main form with nothing on it and a login screen which is successfully bound to my objects. However, there is currently nothing about it which is smart enough to catch which Reviewer you are trying to log in as. Since I have it close the application when an invalid viewer is selected, it currently isn't going very far.
But, the point of today wasn't to get everything done or even in the right order. For today I just wanted to get something fun done on this project to keep the ball rolling. Was feeling sapped and not wanting to code after the past week at work and just wanted to dive into some part of the fun code. So, now I will set aside the tasks for the fifth installment which basically includes all of the boring stuff I skipped or that would have come afterwards anyway.
For installment number 5 I need to address the following 4 items in this order to regain some semblance of doing this project correctly:
- I need to figure out why my collections aren't populating correctly at the database level (from failed test case).
- I need to write more tests for the data access layer.
- I need to write the bindings to track the user selection (collection index) changing on the login screen.
- I need to produce a framework for driving the main frame's control. This is where the main functionality will be housed. Main screens will be here housed in pages while related/extended functionality will come through pop-up windows like the login screen.
I'm going to leave the functionality that closes the application for invalid logins as it is. This is because there are no passwords and the Reviewers are selected from a drop down list. Once the index change tracking is in place, the only way to select an invalid user will be to either select no user at all or to close the window, and I will add code to catch hitting the login button without selecting a user. So this will mean that if you close the login screen, it will close the application. I'm happy with that.
Also, I moved away from the earlier proposed design. Because I have screens that are triggering other screens, to avoid some over complicated framework or issues with circular references in my projects, I merged the View and ViewModel projects I spoke of earlier. If I were writing a larger application, the convoluted framework would be the way to go. With an application of this size, it just didn't make sense.
So, what is new? Well, we have something visual now. It isn't much. But it is there. It gives a rough idea of how I'm going to be architecting the screens, and it shows how Data Binding can work with NHibernate using VM Wrapper Express. I plan on tweaking my designs a bit. I'm going to clean up some of the window loading code by making the ViewModel objects a parameter in the View's constructor like I did with the Login view. only difference is that the Views will also set their own DataContext off of this as well. The code is visibly more coupled this way, but the coupling was there before as well, it was just hidden by either assigning the DataContext after the fact or in the XAML. I don't think I'm sacrificing anything, or at least not much in doing this. And having the ViewModel "known" by the View gives me a little more flexibility as well, though I will try not to abuse that flexibility as I don't want to end up with bad code.
Cheers,
Alex.
Well, there is the link for the fourth installment. I jumped the gun a bit. I didn't clean up the problems I was having with my mappings and dove straight into coding the WPF portion of the application. Right now there is a main form with nothing on it and a login screen which is successfully bound to my objects. However, there is currently nothing about it which is smart enough to catch which Reviewer you are trying to log in as. Since I have it close the application when an invalid viewer is selected, it currently isn't going very far.
But, the point of today wasn't to get everything done or even in the right order. For today I just wanted to get something fun done on this project to keep the ball rolling. Was feeling sapped and not wanting to code after the past week at work and just wanted to dive into some part of the fun code. So, now I will set aside the tasks for the fifth installment which basically includes all of the boring stuff I skipped or that would have come afterwards anyway.
For installment number 5 I need to address the following 4 items in this order to regain some semblance of doing this project correctly:
- I need to figure out why my collections aren't populating correctly at the database level (from failed test case).
- I need to write more tests for the data access layer.
- I need to write the bindings to track the user selection (collection index) changing on the login screen.
- I need to produce a framework for driving the main frame's control. This is where the main functionality will be housed. Main screens will be here housed in pages while related/extended functionality will come through pop-up windows like the login screen.
I'm going to leave the functionality that closes the application for invalid logins as it is. This is because there are no passwords and the Reviewers are selected from a drop down list. Once the index change tracking is in place, the only way to select an invalid user will be to either select no user at all or to close the window, and I will add code to catch hitting the login button without selecting a user. So this will mean that if you close the login screen, it will close the application. I'm happy with that.
Also, I moved away from the earlier proposed design. Because I have screens that are triggering other screens, to avoid some over complicated framework or issues with circular references in my projects, I merged the View and ViewModel projects I spoke of earlier. If I were writing a larger application, the convoluted framework would be the way to go. With an application of this size, it just didn't make sense.
So, what is new? Well, we have something visual now. It isn't much. But it is there. It gives a rough idea of how I'm going to be architecting the screens, and it shows how Data Binding can work with NHibernate using VM Wrapper Express. I plan on tweaking my designs a bit. I'm going to clean up some of the window loading code by making the ViewModel objects a parameter in the View's constructor like I did with the Login view. only difference is that the Views will also set their own DataContext off of this as well. The code is visibly more coupled this way, but the coupling was there before as well, it was just hidden by either assigning the DataContext after the fact or in the XAML. I don't think I'm sacrificing anything, or at least not much in doing this. And having the ViewModel "known" by the View gives me a little more flexibility as well, though I will try not to abuse that flexibility as I don't want to end up with bad code.
Cheers,
Alex.
Comments
Post a Comment