# Architectural Patterns Even though BindKraft is targeted as a framework, in reality it is much more. Often, a framework is associated with strict rules around a specific architectural pattern. The programmers using the framework, must follow these rules, without deviating too much. The typical example are the MVC frameworks, which enforce a very narrow approach of writting applications. Yes, a novice programmer can learn MVC fast, but when the pattern fails to fit more complex requirments, programmers start patching up the system, which can be very difficult at times. In a few words, there is no universal solution. That's why BindKraft aims at a different phylosophy. BindKraft provides alternative ways to implement a specific functionality, leaving the programmer to deside which approach would be best. Therefore, BindKraft can be better described as a platform. It provides the programmers a wide variety of tools and techniques, to do their job, writting applications and extensions. The hope is that, programmers working with BindKraft, will discover this freedom and learn to be more indipendent, and creative. ## View-Code-Data In essence, BindKraft is employing a non-strict **View-Code-Data** pattern, on multiple levels. When using BindKraft, a programmer will see the **View** as the main element in the architecture and not as the final result of a process. This is so, because the programmer is encouraged to use the powerfull [binding](#binding-ref) syntax, directly in the view's markup. This way, he focuses on the main problem in the first place - *How do I represent my data to the client*. The view bindings, serve as a tool to read data, to write data, to call code functions, trigger events, do AJAX request, or change the view itself. Ofcourse, nothing forbbids the coder, from using the **Model-View-Controller** approach, whereever he finds appropriate. In such a case, the code-behind will act as controller, bridging the view with the data context. ### Views The concept of the BindKraft view is defined on many levels, according to the specific usage of the framework. In the [Bindkraft Session](#bindkraft-session-ref) article, we discuss the idea of the workspace, which uses the browser to emulate a desktop environment, with windowing. It is important to note that, this is only one way of using the framework, and it should not be viewed as mandatory in any way. Views can be used on their own, right inside a traditional page layout. A **view** is in essence any ViewBase #### Templates ### Data In practice, all types that inherit from the **BaseObject** class, provide the functionality to send and receive data through AJAX. This gives the ability for almost any object to request resources from the server at any point in time, which makes the entire flow of data highly asynchronous, and on multiple levels - *applications data*, *window data*, *view data*, etc. This asynchronous communication is based on standardized packages called **packets**. #### Packets Packets have a strictly defined format. The BindKraft objects on the client, expect the server to provide packets in a specific structure, which is predefined as standard. These packets can contain JSON encoded data, views, lookups and metadata, depending on the configuration and the request parameters. The XML below shows an example packet response from the server: ```xml <packet> <status issuccessful="1"> <messages><![CDATA[[{"StatusResultType":0}]]]></messages> </status> <data><![CDATA[{"themes":["default","cerulean","cosmo","cyborg","darkly","flatly","journal","lumen","paper","readable","sandstone","simplex","slate","solar","spacelab","superhero","united","yeti"]}]]></data> <views> <normal><![CDATA[<div data-class="TrivialView" data-key="viewroot"> <ul data-class="Repeater" data-bind-$items="{read path=themes}"> <li> <a href="#" data-on-click="{bind source=viewroot path=changeTheme}"> <span data-bind-text="{read}"></span> </a> </li> </ul> </div>]]></normal> </views> </packet> ``` ### Code-behind <!--BindKraft comes with many predefined templates for specific controls and other elements on the view. These templates give the opportunity to quickly build elements with full functionality and presentation in the view. When combined with scripts, these elements can be generated dynamically to give a fluid user experience. !!!!! par !!!!! The power of templates comes from the fact that the programmer is not limited to use the predefined ones. New templates can be written and this can go to the extent where a single view can function with its own set of specific templates.-->