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".
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
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 framework would auto discover the view and would create an example view object like above.
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 asp.net 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 :
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 ...