Following are some issues that made us re-implement the complete functionality from scratch. Later the approach and guidelines that we implemented to avoid the same problem again will be discussed.
Many methods implementing some business logic were used $(‘#id’) to access values. To reuse this code, I’d have had to use exactly same id/classes for elements.
Too many document.ready()
Each script included on the page had its own document ready handler. Multiple entry points made it hard to determine the flow of code.
At some places, very similar or even the same functionality was implemented in different functions. Validation and error handling code was also repeated at a number of places.
Repeated element ids
Same elements id were used at a number of places.
What Affects What?
The Required Solution
To fix this, we needed to separate the business logic from UI logic. E.g. code to update user information on server should not be defined in the click handler of the submit button. We should, instead, put the ajax call in a separate function, taking the user details as parameters. The click handler should gather user details from form elements and pass them to the function. Similarly, use callbacks to update UI when a response is received from the server.
In UI code, we should be able to somewhere define ids of various form fields instead of hard coding field ids everywhere.
Too many document.ready()
There should be only one script with document ready handler, and it should be responsible to initialize various modules used on the page.
Modular approach & What affects what?
We needed an object oriented approach with business and UI logic in separate modules. Also, we needed some sort of mapping between the UI modules and jspx files. This would make it easier to determine exactly what code needs to be updated if something changes on the UI.
We needed to organize modules neatly. The business logic modules should have some sort of hierarchy based on functionality. The UI modules should maintain same hierarchy as the back end jspx files.
The validation and error handling code should be moved outside business and UI logic, in separate modules of their own.
Repeated element ids
It was simple to use unique ids in a single jspx file. However, on a completely rendered page we could still have repeated ids, especially when a jspx file was included more than once on a page. So, while inserting a jspx file, we also needed to wrap it inside a div container with unique id. We also needed some approach to be able to identify each element without specifying complete id-hierarchy.
To implement the changes suggested in the previous section, I had to write some utility modules to handle things such as validation, error handling, a JQuery wrapper to transparently access DOM elements with full id etc.
Following are some design and coding guidelines that I followed while implementing the mobile website.
Jspx Design Guidelines
- Every id in a jspx file should be unique.
- Every jspx file should be included inside a div container of its own; the container should be given a unique id in the jspx file.
- All form fields should use a common markup style at all places e.g. each field should be placed inside a div container with proper classes such as ‘textbox’, ‘disabled’, ‘read-only’ etc
- Organize the code in some meaningful namespaces, clearly separating business logic, UI logic and form validation and error handling code.
- None of the code in business logic must interact with UI. Any of the business logic functions must accept required data and callback functions as arguments.
- The business logic modules should be singletons unless it is required to create multiple objects of the module.
- A UI module should be created for each jspx file.
- For each jspx file included, a module must create objects of each of the module respective to included jspx files.
- Any HTML element should be accessed only by its respective module.
- While creating a child UI module, the parent module must pass the full id of its child jspx’s container div to the child module.
- Define all form fields and HTML elements of the respective jspx accessed in the module.
- While accessing any field by id in a UI module, the field id should be appended to the full id of the container div passed by the parent module. (We implemented a utility module to transparently handle this).
- Define callbacks in each UI module for any event that might be interesting to the parent module. e.g. submitButtonClicked, someCheckBoxChecked etc.
- In case a child module needs to update parent module for some event, it must do so via callbacks. The parent module needs to set these callbacks at the time of creating the child module object.
- Define public functions for actions requested by parent module. e.g. enableSubmitButton(), showSomeHiddenElement() etc.
- In case a parent module needs to update UI for a child module, it must do via public functions exposed by the child module.
- Don’t access HTML element attributes directly. For example, to hide elements don’t change display style. Create CSS classes for each required state of HTML elements and add/remove these classes to update any
Summing up everything, the following is what we achieved by using the new approach for developing the mobile website:
- The business logic is now completely separate from the UI code, and can be used independent of UI code.
- The UI code has direct mapping with the jspx files. If a jspx file is modified, only its respective is modified.
- Since all fields and HTML elements are defined in each module, changing ids of fields in jspx file requires just a single update in its module.
- All JQuery dependent code has been moved to the ModuleHelper module. Although it might still require a lot of other changes, replacing JQuery with any other library requires minimal UI code changes.
- Each HTML element is now uniquely identifiable by its module, even if the jspx file gets included multiple times on the same page.
- Form validations and error handling are now completely removed from the UI code.