Wednesday, January 21, 2015

JavaScript Journey Part 1 (Ninja Returns)

Today's application development is more focused on the web, we have experienced a shift in momentum from a typical desktop, dynamic website/web application to a more advanced web technologies that utilises HTML5, CSS3, Web components, advanced object oriented Java Scripting, AJAX and above all, Single page architecture. Complete evidence can be obtained from every nook and cranny of the web, cloud computing, mobile technologies and smart technologies. Coexisting applications is becoming the future focus, and to do this graciously, we must re-webify and take on the current mindset "The web is now becoming the desktop".

JavaScript is one of the oldest technology that refused to be replaced but instead, continue to get updated and deliver the modern day web, with its complementary technologies (CSS, HTML, XHTML, XML, XPATH), JavaScript is here to stay and to continue to drive forward our desire for very rich disconnected user experience over the web (GMail is a good testimony and the latest yahoo mail).

A not so long time ago, JavaScript was used by many, in its basic form. For form validation, browser navigation, cookie manipulation,  browser histories e.t.c Little did we know that JavaScript does have the potential and capabilities of solving the same complex problems that the modern object oriented compiled programming platform are solving. It is even  more better when the JavaScript V8 engine can run on the server, making JavaScript not just a browser based technology, but a server based technology too.

Single Page Architecture (SPA)
Web based application that runs as a single page but delivers the feel of a desktop over the cloud. This architecture does not favour the post back/refresh mechanism that was a dominant architectural standards sometime ago, though many developers are still doing this, including myself, because SPA is not a one solution fits all problem architecture. There are some real world problems that can only be solved by postbacks/refresh mechanism, in fact, the issues of standardising the W3C standards across all browsers (a.k.a Web components) even makes SPA architecture very difficult to work with, but there are ways around it, communities were formed and we have several OSS (Open source software's) that helps make life a better place to live in the world of SPA. See the below diagrams for the simple architecture cardboard for an SPA architecture.

Components of the single page 

Template engine: there are many available JavaScript template engines available as open source frameworks. They are responsible for rendering the templates which are part of the HTML or are computed as part of the HTML and JavaScript. A template engine would read the template based on known configuration patterns and if based on discover-ability architecture (software following a declarative pattern) would facilitate JavaScript views discovery. The template approach should not only define how data binding should be ensured or if a particular section is a single object binding or multiple object binding. Equally they should specify in the HTML data annotations for discovering a view, a data annotation for exposing triggers, events, handlers, a data annotation for model expression (regex). Will give full coverage of template engine later in other episodes of JavaScript. A good pseudo example of configuring an html section as a template and view is as follows:

 The pseudo template description above leverage's the web components custom element specification. A view is described as x-view with children which can be x-field (for describing fields for data-binding and/or rendering), x-association (for describing the association of inner views, for instance a customer view has multiple address views). More complex information will be given in the template engine section in other episode of this series ...

View engine:  based on the template that are described and pseudo example given above, the view object should be created as to, one view declaration to one view objects. I will give you further hints and approaches to the ways you can create a list view which only data-binds when you bind data, and a view object would be created for an list item when it is interacted with (giving us the power of lazy view object initialisation, and ability to bind 100s of data without worrying about how many views object's that will be created).

The view engine is responsible for the object oriented representation of the view template described in the template engine section. In fact a view object is a JavaScript object that can be described like so:

The framework would auto discover the view and would create an example view object like above.

Security context: a single architecture would require security to be built atop especially the type that assigns roles and responsibilities to the users based on allocation. So for instance, if user A can access a particular section of the SPA/form/view/x-field/associations the relevant security privileges will be allocated to the user. The security concept of an SPA would be to the granular level, security features can be added to views and parts of the view (called view policies). As of writing, there are no interesting security frameworks out there that can provide such level of granularity on the JavaScript side unless it is custom built. I have lead a particular SPA project where we built such rich security features, that it self is an episode on its own. A context object need to be readily available to be passed after a user login, this object would contain context aware information related to the current logged on user. An example is as follows:

above gives a skeletial view of what a typical security context object would contain. more details will be given later.

Observer model: View objects changes (field and association changes) need to be observed, a type called observer model is required, which tracks changes in a view object, as the view object changes, the observer  model changes. This kind of architecture can be traced back to the MVC (Model View Controller) GUI pattern. Fields themselves are observable, the views are observables and provides notifications to the observers or listeners. Also, property change notification can be implemented in the observer model, this will make the observer model to notify interested listeners to register and listen to when a model property changes. The concept of the property change notification makes the observer model observable too (two directional observations).

View Presenter: The presenter pattern is a architectural pattern that enables the events,  model binding and general house keeping functionality for the views. While the view is responsible for controls, rendering and input, the presenter will handle control events, register cross server events, listen to global/user context changes to notify the view. The presenter is where the developer concentrates his/her coding in this architectural style. Events will be handled, forwarded, dispacthed, propagated, delegated etc. The presenter is more concerned with separation of concerns and testability of the core functionality. Presenter is where the code gets interesting, but could become very ugly if all sorts of events and business functionality are handled in there (We need to watch the code-base).

if you go back to the pseudo template engine declaration, you will notice an attribute declaration within the x-view element, this declaration is to specify what presenter is need to be used against the view in question. Back to the presenter declaration above, there three life cycle methods (preInit, init, dispose), these events will be raised throughout some stages in the presenter lifetime. You will also notice the global getView and getEventBus function, they do the exact thing that the code describes. The getView gets the current view that was initialised with this presenter and the get eventBus gets the eventBus that is specifically made for this presenter. The eventBus can be used to listen to both presenter level events, view level events, cross presenter events and of course server sent events in case websockets are in use or the Server Send Events (SSE) is leveraged.

Lookin deeply into the presenter declaration, in the preInit life cycle method, you can get a good example of how view controls/fields events are registered. The example given registered changed event on the firstName field. Also the association added event was registered into when an address view is added, the event is fired.

Server side controller and actions or event web api: The wonderful thing about spa is, it is server side agnostic, it can consume data from different endpoints technologies, languages. It can in fact leverage COR (Cross Origin Request)  to pull data from different domains. We can leverage on the ASP.NET MVC view controllers for servicing the html s and the templates when requested by the spa page, and equally we can leverage on the mvc web api for REST styled architectural data in json format.

Custom controls: the HTML controls cannot be enough, the HTML5 standard controls and functionality will not be enough to build a responsive SPA based architecture, jquery controls are too tied with jquery but can be abstracted into your spa architecture. You need to buy into the idea of custom controls, controls like tree view are not standard HTML controls, nice looking controls like auto complete are not standard controls, so you need the abilities to allow your development to introduce custom control as the requirement of your application gets bigger, or more so, if the same code are to be reusable across your architecture. see an example of custom control :

The control description above, describes a tree node structure. As you must have deduced from the type of the control that it is a "TreeControl", the name is the name that will be given to the instance of that control, note, a control can be a member of a view and some controls can allow for databing from the view observer model, of they are responsible for fetching their own data based on configurations sets. A nicer way to architect a control is to introduce an BaseControl which all other controls can inherit from using a prototypical inheritance of any form of JavaScript inheritance of your flavour.

This is just a quick peek spa architecture intro. I will be introducing more in dept blogs on other useful architectural approaches and patterns that can be used to fulfil the needs of spa.

to be continued ...

No comments: