Jul 24, 2012

Design Decisions

During the first phase of the project I had to make several design decisions. My mentor was a big help on each of them and so far I am pleased with how they turned out. Reading through the chats we had, I am amazed at how many decisions were based on the input of my mentor.

The biggest decision was to base the dashboard on Forms. My DashboardForm subclasses Form. To provide callbacks to the Controllers that are associated with the panels, it intercepts the httpSubmission method. In this case, the idea was mine, but it solidified during a discussion with my mentor.

Another nice example of my interaction with my mentor is the way that adding things to the dashboard is currently handled. I was originally thinking along the lines of directly adding the FormFields to that Form. My mentor suggested using an intermediary object, and thus DashboardPanel was born. After implementing it, I stumbled across a problem with the log tab. When I talked about this to my mentor he told me that Session is initiated at a later stage, making it necessary  to insert data that is loaded via Session at a later point. This lead to the method  getPanelContent, which allows adding data at a later stage.

Yesterday, I ported dbprofiler to my dashboard. It was amazing to see how easy and fast this could be done. It took me longer to switch the jQuery table sorter to an implementation that works with current versions of jquery than to move dbprofiler to my dashboard. If you want to see how it works check out the dashboard branch.

Jul 13, 2012


The midterm evaluations have taken place this week, marking the half time in my project.

So far, I have a working module that can already be used an integrates with the existing SS_Log / Zend_Log infrastructure. The UI is based on SilverStripe Forms, something which developers are already familiar with.

A nice thing this week was the implementation of the DashboardLogFilter, which allows enabling or disabling logs for URL patterns. The Zend_Log infrastructure made writing this very easy, it's just a class that implements Zend_Log_Filter_Interface. At the beginning of the implementation I came across the point where I thought: "there is no way to make sure this works by manual testing", so I actually started writing the unit tests before implementing most of the functionality. This is the first time I tried my hands at a tests first approach and I am very pleased with the way this turned out.

Next week I'll be taking a break, and after that it's back to coding. Apart from the smaller things that are collected in my issues list (https://github.com/jakr/developer_dashboard/issues),  I will try to integrate the existing dbprofiler extension with my dashboard. This is a good first test to see if my API is complete and if someone else's code will actually be able to use the dashboard. And if it works I get a fully functioning query log as a free extra.