As I was writing this series, it cause me to rethink some approaches and redesign part of our MVC framework. Therefore, it took me a bit longer to start this series than I thought. But here goes.
Introduction
The concept of Model-View-Controller MVC can be implemented in two ways, using a server-side component framework that generates the Web application interface/view or as a JavaScript framework that gets data from the server and generates the Web application interface/view .
In this series, we will be discussing how we created and implemented a JavaScript MVC framework. If you a Java developer and would like to implement a server-side MVC framework, Vaadin is a good server-side MVC framework to look into. For developers in the XPages community, Ulrich Krause and Paul Withers has been blogging about Vaadin.
Each approach has its advantages and which approach you use is based on your development skills, tools, and architecture of your web application. If you are a XPages developer and plan to continue implementing web applications strictly on the server-side, I suggest you seriously look into Vaadin and move away from the whole XPages approach. Vaadin provide you a more standardized and reusable approach.
What is an MVC Framework?
The goal with most MVC framework is to separate the application into 3 primary components that are use to generate the interface used to interact with the data, the model (data), the view (presentation), and the controller (manipulator).
If you are using a server-based approach, everything is done on the server. For a JavaScript-based MVC, the client retrieves the data and templates from the server. The controller facilitates the binding process and interface manipulation to generate what you see on the device. One addition component is the router which facilitates the communication between the client and the server. For our architecture, the router is a separate component layer. In some frameworks it is part of the model.
They are many different derivatives of the MVC concept. Some are very basic and some more encompassing. The model can reside both in memory and in local storage. In some approaches, the model structure is a directly reflection of the data on the server and the data is automatically synced. The controller always accesses the model locally whether in memory or local storage. As a result, any changes to the local data propagates back to the server.
Introduction
The concept of Model-View-Controller MVC can be implemented in two ways, using a server-side component framework that generates the Web application interface/view or as a JavaScript framework that gets data from the server and generates the Web application interface/view .
In this series, we will be discussing how we created and implemented a JavaScript MVC framework. If you a Java developer and would like to implement a server-side MVC framework, Vaadin is a good server-side MVC framework to look into. For developers in the XPages community, Ulrich Krause and Paul Withers has been blogging about Vaadin.
Each approach has its advantages and which approach you use is based on your development skills, tools, and architecture of your web application. If you are a XPages developer and plan to continue implementing web applications strictly on the server-side, I suggest you seriously look into Vaadin and move away from the whole XPages approach. Vaadin provide you a more standardized and reusable approach.
What is an MVC Framework?
The goal with most MVC framework is to separate the application into 3 primary components that are use to generate the interface used to interact with the data, the model (data), the view (presentation), and the controller (manipulator).
If you are using a server-based approach, everything is done on the server. For a JavaScript-based MVC, the client retrieves the data and templates from the server. The controller facilitates the binding process and interface manipulation to generate what you see on the device. One addition component is the router which facilitates the communication between the client and the server. For our architecture, the router is a separate component layer. In some frameworks it is part of the model.
They are many different derivatives of the MVC concept. Some are very basic and some more encompassing. The model can reside both in memory and in local storage. In some approaches, the model structure is a directly reflection of the data on the server and the data is automatically synced. The controller always accesses the model locally whether in memory or local storage. As a result, any changes to the local data propagates back to the server.
MVC frameworks can implement either a one-way or bi-directional binding of the model with the view. Bi-directional binding significantly reduces the need to manage the data. One of the best examples of MVCs utilizing bi-directional binding is Angular. At this time, it is the most popular JavaScript-based MVC framework. Marky Roden has done a number of blogs and presentations at MWLUG and IBM Connect relating to Angular. Angular makes it easy for you with the help of some CSS create some very nice applications. Dojo also provides the ability for this two-way binding process, but it requires must more coding than Angular.
Secure MVC framework
As I mentioned in my prologue, our goal was to create a secure MVC framework. So what constitutes a secure MVC framework versus a regular MVC framework? A secure MVC framework has to perform like a regular MVC framework, but must take into account that data and information security trumps over the user interface. At no time can data reside locally on the client. It should only be in memory and if it is no longer needed it should automatically be destroyed. It needs to work in an environment where user access to any particular data at any instance is dynamic, access level is dynamic and may be revoked at any time during a session. It needs to respond accordingly to handle multi access level from the application level all the way up to the widgets level.
In addition, our framework needed to be server technology agnostic and work in a multiple pane environment where user access rights maybe different for each pane. So that was our goal.
Coming Part 2, Design Requirements
Comments
I see where you're coming from and depending on how you implement your client-side code, the bidirectional binding can be problematic. As Angular 1.2(-ish?) brought us "controller as" syntax (which is now the accepted norm), and the direction of Angular 2 is far more in the direction of web components, I believe that without too much effort, you could achieve the something similar in Angular; just not before some of the 1.2 and 1.3 improvements. Still, an excellent point on understanding how you need to structure your available frameworks to do what you need.