Problems encountered during the project and how I solved it

6 Min. Read
Jul 6, 2019

Map rendering

In the project, one of the major problem I faced was during the rendering of the map. The map would only render after the page had been reloaded. After a thorough look through the code, we found that the script tag that renders the map was being being loaded after the script that manipulates the map. Hence, the script tag was moved to the head of the page rather than the body of the page.

Initially, the script tag was included in the body of the slim file or the view file, but after moving the tag to the head part, the application was running flawlessly.

1
2
= javascript_include_tag 'dashboard'
script src = "https://maps.googleapis.com/maps/api/js?(api key)"

was changed to:

1
2
script src = "https://maps.googleapis.com/maps/api/js?(api key)"
= javascript_include_tag 'dashboard'

JavaScript and CSS namespace

In the previous versions of the project, the javascript tags and css tags were included in the same view file. This caused the file to be unnecessarily long and the code looked unorganized. To solve this, the concept of global variable was used throughout the project. An application wide global variable was declared which could be accessed from any part of the project. For the project, the global variable started with the prefix “windows.”. The values that the global variables carried were of dynamic nature.

The global variables were declared in the slim file as:

dashboard.slim

1
window.globalobject.obj = #{rubyobject};

The file was declared required in the respective manifest file. The global object could then be accessed from any place in the project

dashboard.js

1
2
3
4
window.globalobject.map.object.setZoom(7);
window.globalobject.map.object.setCenter({
    variable: window.globalobject.obj
    });

Datepicker widget

Widgets are feature-rich, stateful plugins that have a full life-cycle, along with methods and events.

The datepicker is tied to a standard form input field. Focus on the input (click, or use the tab key) to open an interactive calendar in a small overlay. Choose a date, click elsewhere on the page (blur the input), or hit the Esc key to close. If a date is chosen, feedback is shown as the input’s value.

The datepicker widget was used in the project, such that a user is able to choose the checkin and checkout date, provided by the widget. The minDate option was added so that the user couldn’t choose the date prior than today.

Since, the datepicker widget had pre-defined classes, the css was customized accordingly.

Here’s the API documentation for datepicker: https://api.jqueryui.com/datepicker/

1
2
3
4
5
 $(".checkdate").datepicker({
        dateFormat: "yy-mm-dd",
        minDate: new Date(),
        dayNamesMin: ["Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"],
    });

The css for the datepicker was styled as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
.ui-datepicker {
  width: 225px;
  height: auto;
  margin: 5px auto 0;
  text-align: center;
  background: #ffff;
}

.ui-datepicker table {
  width: 100%;
}

.ui-datepicker-header {
  background: #3e9aba;
  color: #ffff;
}

.ui-datepicker-today {
  background: lightgray;
}

.ui-datepicker-title {
  font-weight: bold;
  font-size: 1rem;
  padding: 10px;
}

.ui-datepicker-prev span {
  float: left;
  cursor: pointer;
  margin-left: 5px;
}

.ui-datepicker-next span {
  float: right;
  cursor: pointer;
  margin-right: 5px;
}

The code above would generate a widget depicted below:

Autocomplete widget

Autocomplete enables users to quickly find and select from a pre-populated list of values as they type, leveraging searching and filtering. The autocomplete feature was used in the project, where the owner could add establishments and an autocomplete option would pop up in the kind field containing values that were already stored in the database.

Like datepicker, autocomplete came with its pre-defined classes. Hence, the css was styled accordingly.

Here’s the API documentation for autocomplete widget: https://api.jqueryui.com/autocomplete/

1
2
3
$("#div-id").autocomplete({
        source: globalObject
});

The css was styled as:

1
2
3
4
5
6
7
8
9
.ui-autocomplete {
  background: #FFF;
  border: 1px solid lightblue;
  list-style: none;
  padding: 4px;
  width: 50px;
  border-radius: 0 0 5px 5px;
  font-size: 1rem;
}

The code above would generate a widget depicted below:

Fail safe code

Before, an action of a model generating an error would effect other pages of other models. This wasn’t desirable as an error in a particular page was being rendered in other pages as well. In other words, an error exploding in one action of the model would hinder or disrupt the flow of other actions of a different model. To solve this, the concept of fail safe codes was introduced.

1
2
3
 if ($('.dashboards.new, .dashboards.edit, .dashboards.create').length == 0) {
        return false;
    }

Bug fix in booking section

When the checkbox were selected in the new action of booking and the counts were entered, and given that errors were generated the create action was invoked, the input field for the count was built the same number of times as that of the entered count in the text field. What happened was, when the new action was being completed, the count was already saved and when the create action was invoked, the count it read was already set by the new action. The problem was solved using the technique below:

1
2
3
 - data = f.object.model.group_by(&:id) || []
  - f.object.model = []
  - f.object.model.build

Instead of building the input boxes in loop according to the number of service count, the build was initiated without the counts in the service.

1
2
3
4
5
 - count = (data[id] && data[id].count) || 1
  - check_condition = (data[id] && count > 0)
    = f.check_box :id, {checked: check_condition}, id
    = f.label :id
    = f.number_field :datta_count, {value: count, in: 0..100}

Using the above technique, the checkboxes that were already checked in the new action was also imitated in the create action.

Similarly, the amount calculation of the new page needed to be imitated in the create page as well. Hence, the following code was added.

1
2
 $('.div-class).change(calcTotal);
 $('.div-class').change();`

The change event was triggered when the document was loaded, making it possible for accurate representation of amount calculation even in create page.

Summary

I am immensely grateful for having been provided with the opportunity to work in this project. The project has enabled with a great deal of knowledge and problem solving skills. The knowledge gained from this project will definitely help me in my future endeavours.