Encapsulation and forwarding

Yesterday I realized that I write more about refactoring than implementation. To stay consistent today’s post is about…refactoring. Well, maybe not only about it, but mainly. In the previous week I finished following tasks:

  • [F-4] Handling request result (response code, message)
  • [F-8] Encapsulate logic from aksesi-gesture.js into a class
  • [F-9] Secure initialization
  • [P-1] Forwarding requests to an authentication endpoint

I would like to remind you that all of the sources are available in my Github repository. Moreover, in the README file, you can find short project description with its main assumptions.

Encapsulation and initialization

There is an aksesi.js file. The file is responsible for binding UI events with handlers. Previously all of the values and inner objects were available through the global stack. It wasn’t good solution due to the lack of encapsulation. Moreover, another module or script was able to edit the module state, e.g. removing gesture points. The solution with which I came up was to encapsulate the whole logic of handling events into a class. The class I created is named AksesiEventHandler. It provides methods like keyUpEvent, keyPressEvent so in the place of binding events (aksesi.js), we can call appropriate handler. Of course, I also moved all of the variables into the AksesiEventHandler class. On yesterday’s evening, I made additional changes connected with better encapsulation. I refactored the class to use a return {} statement. I do not quite understand this convention but I’ll read about it in the future.

To sum it up, AksesiEventHandler class knows how to handle all of the events generated by the frontend module.

Another thing that has changed is module initialization. The aksesi.js file provides only init method which cares about necessary configuration. A user does not have to care about $(document).ready(function() {}) call:

As you can see the above method as a parameter takes a configuration array instead of the list of arguments. I think that this convention is more user-friendly. Thanks to it, in a place where a user calls the init() method, it is known which parameters are initialized and what value they have.

The last thing I want to mention in this paragraph is the _handlerResponse method. Simple function which is responsible for printing a response received from the proxy application. In this case, it is converted password. The message area is automatically appended to the form during the initialization process.


Aksesi’s main idea is to act as a proxy in the authentication process. Thus far, we were able to convert a password. Let’s think a while what we need to prepare to pass a request to an authentication endpoint. URL and request method for sure. What else? We should know how to build a request body i.e. pairs of keys and values of sent data. In Aksesi’s case it shouldn’t be a problem because it’s easy to retrieve those values from a login form:

I’ve prepared dedicated value object which consists of a login form elements names – login input name and password input name. Having those names it is possible to prepare appropriate configuration object and send it to the proxy application:

I did the same thing on the backend side by editing ConfigurationDTO class:

The creation of a request, which will be passed to an endpoint, is rather trivial. I encapsulated it in the class (for sake of tests!) named AuthenticationRequestProvider:

In the PasswordController, the  AuthenticationRequestProvider is called:


From now on, the Aksesi Proxy is ready to forward authentication requests to client’s endpoints. In the near future, I’ll a build demo project for testing purposes.

You may also like