Hello again, and welcome to my project blog, perhaps the driest and least entertaining blog you'll find on the Internet. For my purposes, it will be invaluable. For yours, I recommend a hearty helping right before bed as the ultimate sleep aid.
Back to the matter at hand.
In my initial projected timeline, I saved the creation of the GUI for the last step. I designed Chef Helper with a 3-tier architecture in mind, trying to keep with what I understand the industry standard to be. And the way I understand a 3-tier architecture is a data layer, a logic layer, and an interface layer all working together but being modular and individually replaceable. So to run the same program on a different interface should only require changes to be made to the interface layer without affecting the other two tiers.
With that goal in mind, I scheduled to start at the data, move into the logic, and finish with the interface. However, as I was spending all that time working on my data store (see last post), I realized that I wasn't totally sure how I wanted the data to come out the other end. More specifically, I didn't really know how I wanted it to look and be accessible to the user. Hoping to clarify that connection to the user, I started drawing up some prospective windows just on scratch paper and started thinking about what layout makes the most sense from a user's perspective.
While I still haven't firmly decided on a lot of the interface layout and design, I did realize that I needed to fit the interface into Java's Swing architecture and I didn't really remember much about how those components are created or interact. So it was back to the books for me. Unfortunately, Java Swing is a somewhat under-utilized method of creating user interfaces and good information on it is rather scarce. Oracle (formerly Sun) provides a lot of documentation but it's all based on how the component classes are structured rather then how to actually use them to build an interface. It took me weeks and money to find a couple of good resources and a good way to approach the interface.
'Why does this matter at this stage?' you're probably wondering. Well, I realized that while I now knew what the interface between the logic layer and data layer would look like, I had no idea how to get from there to the user interface. I had to to quite a bit of research on Java Swing just to get an idea of how its classes were going to fit together to create a usable interface. I also had to relearn how to use the NetBeans IDE, since it remains the best program I know of for drawing out the user interface in a WYSIWYG environment.
The funny part about all this is that once I got a clearer picture of how I wanted the data to look to the user, I realized that my MySQL tables were going to be inadequate for a lot of the needed functionality. So I went back to the drawing board and redesigned a number of tables to create a functional and ultimately cleaner data structure.
I am still waiting to flesh out the GUI until I get the logic in place, but I have decided that I need to break the logic layer down into two pieces of its own. Instead of being one piece that accesses the data, processes it, and displays it to the GUI, I've decided it makes more sense to have a database connection logic section and a separate section to represent the Chef Helper objects in Java and ultimately work with and display them.
The Java DataBase Connectivity (JDBC) class turns out to be rather complicated and convoluted with many nested loops, try/catch blocks, and exceptions, so I'm going to work on the logic section next instead.
And that recap brings us up to today and my current tasks for completing Chef Helper, with very little time remaining and a lot of interruptions already in my schedule. Wish me luck!
No comments:
Post a Comment