Weekly update #6 [15/7-21/7]

This week my task was to create a view for an error report. I finished it successfully. I have created 2 views one that shows the summary of all the submitted reports showing the most important info and the other shows the details of a specific incident

The detailed view is a pure json view that has all the information collected. The reason I kept the view as json is that there was too much information for it to easily fit in a usable interface. When I was doing an html display I was cramming a lot of information and trying to make it look good with the layout. The json saved me from that and allowed me to only include the info that I think would be most suitable and leave the others out to the detailed view. it is also pretty printed so its still easy to manage.

I have tried to make my code as modular as possible so that any change in one part should not impact the other parts. I have left all but the simplest queries out of the controller and implemented them as methods in the model. This is a good approach since it allows me to change the schema of the database and leave the controller and views untouched.

Speaking of changing the schema, the current schema is implemented such that all submitted reports are given first class treatment in the sense that they are listed separately in the index and each has its own view. however this is increasingly not the case, since most likely most of these reports would just be repetitions of an older issue or bug and should not get the same treatment as a new bug or issue.

This is currently implemented by an extra column in the reports table pointing to the id of the report of some similar report. Thus reports without an entry in this column should be given preferential treatment than reports that do.

So I am thinking of changing the schema into two different tables. one for reports and the other for incidents. the incident is a submission that matches a report such that all incidents for a specific reports are for the same bug. and a report has many incidents.

Due to the separation of responsibilities I am able to do the change with minimum changes in the controller and view. I will probably do this in the weeks allotted for grouping reports together since this is the most relevant week and will already include a host of changes to allow for the grouping of reports anyway.

Next week I am going to implement sourceforge api submission. It would allow developers to just automatically submit reports to the sourceforge issue tracker for the developers to work on. The only issue left is access control, in the sense that who can submit these reports?


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s