Spoke too soon...
Went out for a Timmie's date with Veronica... there were indeed some bugs. So I did do some code tonight after all.
Bugs were fairly minor, HST discounts (people eligible for 5% HST vs the full 13% which we're not even sure is a valid situation at the moment) was not being calculated correctly due to the poor way in which I implemented it *frown*. But fixed it easily enough nonetheless. And when a customer pre-paid for an order the system was not correctly updating the status to PaymentsMade because I had opted not to clutter my database design with an NHibernate controlled version number so I was able to overwrite new changes with an old version of the object *frown again*.
And lastly there was an item to change the way something was represented on the invoices after all.
However, this kind of brought me back full circle to an earlier post where I had said that I would look into things I may have avoided doing the right out on in my personal projects because no one was paying me to do it properly and they would have been redundant or boring. While it didn't take me long to fix the problems, it invariably could have taken substantially less time. Both of the bugs were in my single biggest (and most cluttered) screen and it took me some time to A) Find the code to change and then B) Remember what their role was in this huge monolithic form.
Now, the point I'm about to make only partially ties back into my earlier post. In theory, I didn't cheap out on what I'm about to talk about. I HAD tried it... I simply hadn't been able to make it work. But at the same time, I also apparently didn't make the effort to find out why it wouldn't work *frown yet again*. When I first started dabbling in WPF and Silverlight (actually some time before I even began on Version 2) I was incredibly excited about this new technology, especially the data binding. All of the samples and examples compiled and ran like a dream. All of the basic data types I bound, ran like a dream... And every time I tried to plug in NHibernate it blew up in my face with a completely undebuggable error where, no matter what I did it always spewed the same error that pointed to line 1 in a XAML file I hadn't even modified. It WAS the app.xaml file, but I still don't feel that justifies the completely useless message.
So, when I started on my designs for Version 3 I decided to google my problem, and found this:
http://www.codeproject.com/KB/WPF/WpfNhibernateToolkit.aspx. I knew I had found the right article after the first two sentences "WPF is great--really. NHibernate is great, too. But they don't like each other—at all". It summed up my thoughts up until this point perfectly.
Link above basically was helpful twofold. First of all, it helped me realize that the exploding code wasn't because I had done something inherently wrong, and the other was it showed me where in the grand scheme of things Microsoft wants my so that I can start getting useful exceptions again.
So, how does this tie back to my code issue today? Having done a few prototype screens in WPF and Silverlight for Version 3 already, I couldn't help but feel as I went through the tangle of code that the stark lines between drawn in your code between the UI and functionality imposed by the MVVM would have made finding what I was looking for a lot more intuitive. And, even more than the fact that I liked that aspect of the separation, what I liked more about the project designs in the code provided in the above link was that all of the buttons were delegated to separate classes that inherited the ICommand interface. Had I done such a thing in my code, knowing the check box that triggered the HST calculation was causing issue, I could simply have, without even looking at the UI, or the work flow gone straight to the HSTChangeCommand (or similarly named) class. There would be a lot of these boring Command objects as the project grew, some containing just a few lines, but as long as they are done right they would have made a good project even better. The icing on the cake in this article is that the demo application is actually a Code generator built using the techniques discussed which will auto generate the wrapper classes for the domain objects and collections. Kudos to David Veeneman for both his excellent work and explaining why my application was causing my headaches.
So, on that note, with Veronica having accepted that she is my guinea pig... and segue between the design phase and implementation phase of version 3, will be taking a pit stop to write a new WPF version of the UI implementing some of these techniques and functionality while bringing some of the standards I want in version 3 back into Version 2. Having someone who can test it in a real world environment before starting version 3 will hopefully provide some good insight.
And now I'm inadvertently psyched about coding my side projects again.
Cheers,
Alex.
Bugs were fairly minor, HST discounts (people eligible for 5% HST vs the full 13% which we're not even sure is a valid situation at the moment) was not being calculated correctly due to the poor way in which I implemented it *frown*. But fixed it easily enough nonetheless. And when a customer pre-paid for an order the system was not correctly updating the status to PaymentsMade because I had opted not to clutter my database design with an NHibernate controlled version number so I was able to overwrite new changes with an old version of the object *frown again*.
And lastly there was an item to change the way something was represented on the invoices after all.
However, this kind of brought me back full circle to an earlier post where I had said that I would look into things I may have avoided doing the right out on in my personal projects because no one was paying me to do it properly and they would have been redundant or boring. While it didn't take me long to fix the problems, it invariably could have taken substantially less time. Both of the bugs were in my single biggest (and most cluttered) screen and it took me some time to A) Find the code to change and then B) Remember what their role was in this huge monolithic form.
Now, the point I'm about to make only partially ties back into my earlier post. In theory, I didn't cheap out on what I'm about to talk about. I HAD tried it... I simply hadn't been able to make it work. But at the same time, I also apparently didn't make the effort to find out why it wouldn't work *frown yet again*. When I first started dabbling in WPF and Silverlight (actually some time before I even began on Version 2) I was incredibly excited about this new technology, especially the data binding. All of the samples and examples compiled and ran like a dream. All of the basic data types I bound, ran like a dream... And every time I tried to plug in NHibernate it blew up in my face with a completely undebuggable error where, no matter what I did it always spewed the same error that pointed to line 1 in a XAML file I hadn't even modified. It WAS the app.xaml file, but I still don't feel that justifies the completely useless message.
So, when I started on my designs for Version 3 I decided to google my problem, and found this:
http://www.codeproject.com/KB/WPF/WpfNhibernateToolkit.aspx. I knew I had found the right article after the first two sentences "WPF is great--really. NHibernate is great, too. But they don't like each other—at all". It summed up my thoughts up until this point perfectly.
Link above basically was helpful twofold. First of all, it helped me realize that the exploding code wasn't because I had done something inherently wrong, and the other was it showed me where in the grand scheme of things Microsoft wants my so that I can start getting useful exceptions again.
So, how does this tie back to my code issue today? Having done a few prototype screens in WPF and Silverlight for Version 3 already, I couldn't help but feel as I went through the tangle of code that the stark lines between drawn in your code between the UI and functionality imposed by the MVVM would have made finding what I was looking for a lot more intuitive. And, even more than the fact that I liked that aspect of the separation, what I liked more about the project designs in the code provided in the above link was that all of the buttons were delegated to separate classes that inherited the ICommand interface. Had I done such a thing in my code, knowing the check box that triggered the HST calculation was causing issue, I could simply have, without even looking at the UI, or the work flow gone straight to the HSTChangeCommand (or similarly named) class. There would be a lot of these boring Command objects as the project grew, some containing just a few lines, but as long as they are done right they would have made a good project even better. The icing on the cake in this article is that the demo application is actually a Code generator built using the techniques discussed which will auto generate the wrapper classes for the domain objects and collections. Kudos to David Veeneman for both his excellent work and explaining why my application was causing my headaches.
So, on that note, with Veronica having accepted that she is my guinea pig... and segue between the design phase and implementation phase of version 3, will be taking a pit stop to write a new WPF version of the UI implementing some of these techniques and functionality while bringing some of the standards I want in version 3 back into Version 2. Having someone who can test it in a real world environment before starting version 3 will hopefully provide some good insight.
And now I'm inadvertently psyched about coding my side projects again.
Cheers,
Alex.
Comments
Post a Comment