Introduction to NikaFramework (NKF). Part 1

What is NikaFramework?

NikaFramework is an architectural JavaScript framework for Web UI developers.
The first thing to understand is that this is not a UI framework, as for example. ExtJS or SmartClient.
This is a framework that is designed to organize your code, to make writing complex dynamic pages a simple exercise, while leaving the opportunity to independently impose a page at the discretion of the developer.



What tasks does the framework solve?

1. Organization code
One of the problems of writing large web applications is that the code is often not organized, and different parts of the function are in files that do not correspond to the name in the meaning. It is also a problem that you cannot tell 100% where that or a certain part of the function will be.
')
To solve this problem, NKF divides the page into its components:
layout (layout), page (page), widget (widget), component (component).

Layout is a global view layout, for example. logged in / unlocked which will not change when changing pages. For example, if we have a non-logged state, then we simply show the logo on top, and the footer below.



But if the user is in a logged state, then we show on top of the menu, where you can navigate through the pages.



Layout is not necessarily a logged / unlogged state. It can also be used as a layout for reference, a wiki, where the markup is originally different.

Above the layout is a component - page. These are ordinary pages like on standard websites, for example. Home, About Us, Products, etc.
The page itself is very similar to the layout (layout), with one difference that changing the page changes its content, while the layout changes only when changing the global view (logging / non-logged / help / wiki, etc.) ).

And the layout (layout) and page (page) consist of widgets (widget). Of course, no one forbids you to write HTML directly in the layout (layout) and page (page).
But it is more rational to take out f-nal in widgets. Widget (widget) is the user part of the UI of the f-nala. For example If you look at the gmail page, then the widgets can be roughly divided into:
- Header (above)
- Actions (left)
- GTalk (left)
- MailList (center)

Such a partition is convenient because then this widget is easy to find and rewrite, since it is located in a certain, previously known place.



Now let's see how to store NKF files.
xhtml - in dom
css, scss - in style
json - in data
js - in logic
drawings - in img
+ you can create your own options

So you always have a clear code organization.



2. Layout in the classic form
This may seem ridiculous, but JavaScript UI frameworks such as ExtJS, SmartClient, and others - this is a purely declarative writing of JavaScript code, which is then converted to the required DOM.
This means that it is extremely difficult to do something in your own way, because the UI framework dictates its own style to you.

For me personally, as a true Web UI developer, this is very important.

Here, the approach to writing code remains classic.
First we typeset (HTML), then we style (CSS) and we add logic (JavaScript).

For these purposes, you can write code in the dom folder. For example we have a Header widget. So by default we create the index.xhtml file and write its markup.
In the style folder we create a file with any name and with the extension .css or .scss and write styles there.
How to write logic - it will be in a separate article.

Nothing more to do. The NKF project build system itself will take all the files, convert them into what is needed, and you will see your markup, the styles and logic that you wrote.

3. Access to resources on demand
This feature is one of the important features of the NKF.
Imagine that we need to write a simple Menu widget, in which there are just 3 items.

And so, in dom / index.xhtml we write the main markup.
In data / menu.json we will keep for ourselves a predetermined data set for the menu.
In dom / item.html we describe the markup for one menu item.

dom / index.xhtml:

<div class="menu-list"> <ul></ul> </div> 

dom / item.xhtml:

 <li> <a /> </li> 

data / menu.json:

 [ { "id": 1, "name": "Home", "url": "/home" }, { "id": 2, "name": "Products", "url": "/products" }, { "id": 3, "name": "Contacts", "url": "/contacts" } ] 

logic / Menu.js

 /* .... */ //   index.xhtml,     .  var domComponent = this._getComponent(); //   data/menu.json,    var menuData = this._getComponent({ componentPart: "data", // data  JSON componentPartName: "menu" }); //   dom/item.xhtml var itemEl = this._getComponent({ componentPartName: "item" //    xhtml  }); var root = domComponent.find("ul"); $.each(menuData, function(key, value) { var el = itemEl.clone(); el.find("a").attr({ href: value.url, "data-id": value.id }).text(value.name); root.append(el); }); /* .... */ 

That's the finished menu. Notice that in JavaScript we do not write pieces of HTML code, but only
We operate DOM. I also note that index.xhtml, item.xhtml, menu.json is not pulled using AJAX, but already on the client side, thanks to the Web Resource Bundle method for packing resources and building the project, and you can access them inherited methods.
I would also like to note that the only file that will need to be written in the project configuration file is Menu.js.
All other resources will be enabled by the build system automatically.

Continuing ...