Введение в NikaFramework (NKF). Часть 1

    Что такое NikaFramework


    NikaFrameworkархитектурный JavaScript Framework для Web UI разработчиков.
    Первое что нужно понять, что это не UI-ный фреймворк, как напр. ExtJS или SmartClient.
    Это фреймворк, который призван организовать ваш код, сделать написание сложных динамических страниц простым занятием, при этом оставив возможность самостоятельно верстать страницы на усмотрение разработчика.

    NBikaFramework Logo

    Какие задачи решает фреймворк?

    1. Организация кода
    Одна из проблем написания больших веб-приложений является то, что часто код не организован, и разные части ф-ности находятся в файлах, которые не отвечают названию по смыслу. Так же проблемой является то, что вы не можете на 100% сказать, где будет находиться та или определенная часть ф-ности.

    Для решения этот проблемы NKF делит страницу на составляющие компоненты:
    layout (макет), page (страница), widget (виджет), component (компонент).

    layout — это глобальный макет вида, напр. залогиненний/незалогиненный который не будет меняться при смене страниц. Напр., если у нас незалогиненное состояние — то мы просто показываем сверху логотип, а внизу футер.



    А вот если пользователь в залогиненном состоянии — то мы показываем сверху меню, где уже можно переходить по страницам.



    Layout это не обязательно состояние залогененный/незалогиненный. Оно так же может использоваться как макет для справки, wiki, где разметка изначально другая.

    Поверх layout идет компонент — страница (page). Это обычные страницы как на стандартных сайтах, напр. Home, About Us, Products и т.д.
    Сама по себе страница очень похожа к макету (layout), с одним отличием, что при смене страницы меняется ее содержимое, в то время как макет (layout) меняется только при смене глобального вида (залогенений/незалогиненый/справка/вики и т.д).

    И макет (layout) и страница (page) состоят с виджетов (widget). Конечно вам ни кто не запрещает писать HTML прямо в макете (layout) и странице (page).
    Но болeе рационально вынести ф-нал в виджеты. Виджет (widget) это пользовательская часть UI ф-нала. Напр. если глянуть на страницу gmail, то в виджеты грубо можно будет разделить на:
    — Header (сверху)
    — Actions (слева)
    — GTalk (слева)
    — MailList (центр)

    Такое разбиение удобно тем, что потом данный виджет легко найти и переписать, так как он находиться в определенном, заранее известном месте.

    Пример структуры реального проекта

    Теперь посмотрим как предлагает хранить файлы NKF.
    xhtml — в dom
    css, scss — в style
    json — в data
    js — в logic
    рисунки — в img
    + можете создавать свои варианты

    Таким образом у вас всегда четкая организация кода.



    2. Верстка в классическом виде
    Это может показаться смешным, но JavaScript UI фреймворки, такие как ExtJS, SmartClient и другие — это сугубо декларативное написание JavaScript кода, который потом преобразуется в требуемый DOM.
    Это значит, что что-либо подизайнить, сделать по-своему крайне затруднительно, потому что UI фреймворк диктует вам свой стиль.

    Лично для меня как истинного Web UI разработчика, это очень важно.

    Здесь, же подход к написанию кода остается классическим.
    Сначала мы верстаем (HTML), потом стилизуем (CSS) и додаем логику (JavaScript).

    Для этих целей, вы можете писать код в dom папке. Напр. у нас есть виджет Header. Значит, по умолчанию создаем файл index.xhtml и пишем его разметку.
    В style папке создаем файл с любым названием и с расширением .css или .scss и там пишем стили.
    Как писать логику — это будет в отдельной статье.

    Больше ничего делать не надо. Система сборки проекта NKF сама возьмет все файлы, преобразует их в что нужно, и вы увидите свои разметку, стили и логику которую написали.

    3. Доступ к ресурсам по требованию
    Эта ф-ность является одной из важных возможностей NKF.
    Представим, что нам нужно написать простой виджет Меню, в котором просто 3 пункта.

    И так, в dom/index.xhtml пишем главную разметку.
    В data/menu.json будем хранить себе заранее определенный набор данных для меню.
    В dom/item.html мы опишем разметку для одного пункта меню

    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);
    });
    
    /* .... */
    

    Вот и готовое меню. Заметьте, что в JavaScript мы не пишем куски HTML кода, а лишь
    оперируем DOM. Так же обращаю внимание, что index.xhtml, item.xhtml, menu.json не подтягиваются при помощи AJAX, а уже находяться на стороне клиента, благодаря методу по упаковки ресурсов Web Resource Bundle и системе сборки проекта, а доступиться к ним можно при помощи унаследованных методов.
    Еще хотелось бы отметить, что единственный файл, который нужно будет прописать в файле конфигурации проекта, это Menu.js.
    Все остальные ресурсы, будут включены системой сборки автоматически.

    Продолжение
    Поделиться публикацией

    Похожие публикации

    Комментарии 36

      0
      под кат бы часть статьи…
        +2
        спасибо, поправил.
        +2
        А чем NikaFramework лучше Backbone'а?
          0
          Backbone не определяет структуру страницы. Вообще не определяет никакую структуру — есть три базовых класса и крутись как хочешь:) Сходу можно сказать, что вообще в NikaFramework рамки гораздо строже. Иногда это лучше.
            0
            Ну это если голый backbone. А если с плагинами, то может и определять.
            Тот же github.com/marionettejs/backbone.marionette
              0
              Все равно он не диктует расположение файлов, например.
                0
                Согласен. Не диктует.
                (Впрочем, у меня это рельсы делают. И за сборкой в один упакованный файл в продакене следят они же...)
            0
            Очень хороший вопрос к стате, так как NKF сам по себе похож на Backbone.js хотя бы тем что тот тоже по сути являеться по большей части архитектурный.
            Но во первых, NKF не навязывает вам стиль написания как это есть в Backbone (если не возможность в Backbone писать в стиле jQuery way).
            Так же оптимизация трафика, так как все ресурсы тянуться одним файлом — index.htmlz, локализация на лету, семантика DOM и другое. Но об этом в продолжении.
            +1
            смущает вот такой кусок:
                el.find("a").attr({
                    href: value.url,
                    "data-id": value.id
                }).text(value.name);

            Не лучше ль было предусмотреть какой-то шаблонизатор (а желательно, с возможностью замены на свой)?
              –2
              Я негативно отношусь к шаблонизаторам (я лично работал с проектом, шаблоны которого были порядка 1000 строк очень сложных макарон), так как последнии зачастую ведут к тому что код который должен был быть простым, оказываеться через-чур сложным в итоге.
              Сначала код простой, и там лишь подстановка данных объекта. Но потом, нужно добавить проверку на возможность пользователя видеть какой-то блок — уже у нас проверка. Дальше появляеться нужда в итерации, пройтись по чем-то и на основании какой-то логики показывать тот или иной кусок… В этоге шаблон превращаеться в смесь HTML и Логики (ala JavaScript).
              Поэтому я предпочитаю писать куски XHTML отдельно, а в логике строить сколько угодно сложный DOM. Шаблоны этим сильно ограничены, потому что если посмотреть — то шаблоны это сильно упрошенный ЯП.
                +1
                Ну… вам попадались плохие шаблонизаторы, очевидно.
                  +1
                  Нет, скорее, не умеет их готовить.
                  я предпочитаю писать куски XHTML отдельно, а в логике строить сколько угодно сложный DOM

                  Что мешает вынести «куски» в отдельные небольшие шаблончики, а потом подставлять в шаблон верхнего уровня, как готовые строки? Ровно тот же подход получится.
                    0
                    Еще раз. Я не люблю шаблоны из-за того что логика оказывается в двух местах: частично в шаблоне, и в JS. Плюс у вас всегда есть соблазн написать в шаблон лишнего, благо на сегодняшний день шаблонизаторы мощные.
                    Таким образом, я предпочитаю разделять мух от котлет.

                    Приведите мне хороший пример шаблона по вашему мнению (на jsfiddle напр.), чтобы можно было аргументированно обсуждать дальше.
                      0
                      Если вы внимательно посмотрите мой коммент, можете заметить, что я как раз не считаю, что дело в «хорошести» шаблонизатора. И вполне согласен с отделением логики и шаблонов. Но это ни коим образом не противоречит идее шаблонизаторов. Просто не нужно все толкать в один шаблон.
                      Ну, например, у вас есть таблица, строки которой зависят от прав пользователя, исходных данных, выбранного пользователем скина и еще кучи проверок. Если эти проверки толкать в один шаблон — согласен, получится лапша.
                      Но почему бы не сделать несколько «шаблонов для строки» и (анализируя все условия) не отрендерить эти строки по отдельности? Потом в итоговый шаблон можно подать просто список готовых строк и там не будет никакой логики.

                      С этой точки зрения я, для себя лично, «хорошими» считаю наиболее простые и понятные шаблонизаторы без всякого навернутого функцинала. Что-нибудь типа handlebarsjs.com/ Но кому-то может нравиться что-то другое — не принципиально.
              0
              И, простите за интимный вопрос — что у вас с русским языком? Я вижу, что вы из Львова, но у вас прямо-таки англицизмы в тексте (притом на сайте английский со славянизмами).
                +1
                Справедливости ради, ExtJS это далеко не только UI fw. Там и работа с данными, и MVC, и шаблонизация, т.д.
                С выходом Sencha Cmd каркас аппликухи вообще парой строк в консоли делается. А потом минифифицируется и всякое такое.
                Имхо — не совсем уместное сравнение.

                В доках смутило:
                .htaccess — need for correct working framework
                Зачем статике апач?

                По работе с сервером что-то тоже ничего не нашел готового в доках — руками работать?
                Там в доках авторизация вообще интересная:

                        if (username && password) {
                          //Do login, if any credentials were entered
                          $.cookie("isLogin", true, {path: "/"});
                             ...
                        } else {
                          alert("Please enter login and password!");
                        }
                


                Ну спишем на упрощение для примера.

                Хотя на сайте написано — Architectural Web UI Single-Page Application (SPA) Framework.
                Тогда тем более с экстом и т.п. сравнивать не нужно, это он UI — ный)
                  0
                  Ну бы поделил фреймворки на UI и архитектурные. UI это изначально нацелены на создание графического интерфейса, типа гриды, листы, батоны и все такое. То есть все унифицировано, все быстро, все по шаблону.
                  Архитектурные — такие как Backbone.js — они на UI не завязаны. Пиши на чем хочешь. У них цель другая. Это помочь с архитектурой UI.
                  Тем более я не сравниваю их, а наоборот говорю что они в корне отличаються
                  > Первое что нужно понять, что это не UI-ный фреймворк, как напр. ExtJS или SmartClient.

                  На счет .htaccess — посмотрите в него и сразу поймете зачем он.

                  > Зачем статике апач
                  Этого я не понял…

                  > По работе с сервером
                    0
                    нечаянно отправило…

                    > По работе с сервером что-то тоже ничего не нашел готового в доках
                    Это frontend… он не диктует на чем написан backend… либо я не понял вопроса

                    > Architectural Web UI Single-Page Application (SPA) Framework
                    Не просто UI а Web UI… А Web UI — это специальность, в которой программист использует три ключевых технологии, это: HTML,CSS и тонны JavaScript
                      0
                      Ну вот я о том и говорю, что экст не просто хелпер для быстого создания графического интерфейса типа гридов etc, это вполне себе полноценный mvc fw, я не согласен что можно сказать экст — это UI-ный фреймворк. В общем-то, никто не мешает не юзать экстовый UI — хоть джейквери цепляй да отображай как хочешь.

                      > Зачем статике апач
                      Этого я не понял…


                      Статику (css, js… ) лучше раздает nginx, а он .htaccess не понимает. Ну хотя это не большая проблема.

                      > По работе с сервером что-то тоже ничего не нашел готового в доках
                      Это frontend… он не диктует на чем написан backend… либо я не понял вопроса


                      Я имею ввиду — мне нужно отправить запрос на сервер. Ну например для той же авторизации. Или для CRUD. Аякс руками писать? В коробке никаких аяксов нету?
                        0
                        Не спорю, ExtJS это уже монстр, посравнению какой он был когда-то… Но я его отношу к UI потому что это его основное предназначение. То что он MVC — это побочный эффект того, что он стал очень мощный, и нужно все это как-то разруливать. Просто сказать что ExtJS архитектурный фреймворк язык не поворачивается. В первую очередь его достоинство — это UI. Хотя конечно в нем есть часть по работе с архитектурой, но в рамках своего же продукта…
                        P.S. я тоже люблю ExtJS :)

                        Статику (css, js… ) лучше раздает nginx, а он .htaccess не понимает. Ну хотя это не большая проблема

                        Да, можно и nginx. Просто делаете соответствущие настройки…
                        К стате вы не внимательно читали, там не придеться тянуть CSS, JS и прочие… Это уже все будет упаковано в один файл на выходе — index.xhtmlz

                        Я имею ввиду — мне нужно отправить запрос на сервер. Ну например для той же авторизации. Или для CRUD. Аякс руками писать? В коробке никаких аяксов нету?

                        В коробке есть класс NetworkManager и StorageManager. Но это просто посредники, которые удобно использовать когда приложение работает в online/offline режимах. Тогда через класс NetworkManager должна тянутся уже сохраненная инфа с StorageManager, а тот в свою очередь смотрит от куда вытянуть данные (Memory, Cookie, LocalStorage). Но оно во первых не дописано до конца, во вторых нормально не тестировалось.
                        Я напр. использую $.ajax() и не вижу смысла использовать хелперы, если конечно не требуеться вышеописаный механизм.

                        Как я и говорил — NKF не навязывает свой стиль написание. Главная задача это организация кода, возможность верстать в классическом виде, оптимизация траффика через упаковку всех ресурсов, локализация на лету.
                    0
                    Не в упрек ТС и авторам фреймворка лично, но — отдача index.xhtmlz подразумевает, что после каждого изменения исходников требуется сборка/компиляция проекта. А компиляция веб-приложения, имхо, на корню убивает весь фан от разработки (вместо Ctrl+S, Alt+Tab, F5 теперь Ctrl+S, Alt+Tab, make build + пауза, Alt+Tab, F5).

                    Интересно, мне одному это не нравится?
                      0
                      Лечица легко

                      * inotify under linux
                      * builders under IDE
                        0
                        Не панацея — для любого проекта крупнее Hello World сборка будет занимать как минимум несколько (очень раздражающих) секунд. Так что все равно надо будет альт-табиться в консоль и смотреть, собралось уже или нет.
                        На предыдущем проекте у меня было именно так, и бесило жутко.

                        P.S. А пустой проект на GWT вообще собирается минимум полминуты, брр.
                          0
                          Ааа… Тогда надо вводить некий режим разработки, когда можно сразу смотреть, без компиляции.

                          Баг на гитхаб забейте :)
                        0
                        OK. Возьмем для примера средний проект в котором 30 JS файлов. Вы представляете как мучаеться браузер пока сделает 30 реквестов и начнет рендерить. К тому же известно, что любой тег script останавливает работу по загрузки ресурсов, пока
                        JS файл не будет скачан до конца. Даже если использовать аттрибут async тогда нарушаеться последовательность подключения JS файлов, что приведет к ошибке, так как какой-небудь модуль будет вызван прежде нежели будет определен (то есть скачан и исполнен). Даже если обходить этот методом динамической вставки script тега в DOM, все же остаеться латентность на время выкачивания ресурса браузером (напр., на много быстрее будет скачать один большой файл нежели 100 но маленьких файлов).
                        Так что даже спростой cat всех файлов в один даст очень большой прирость произодительности.
                        Тем более процес компиляции идет на NodeJS и занимает в среднем 1 секунду.
                          0
                          У меня был проект из 188 файлов. Собиралось оно питоном и далеко не одну секунду. Но проблема не только в этом, а в том, что дебажить ЭТО — сущий кошмар.

                          На стадии разработки мне пофиг, сколько там кряхтит браузер.

                          В текущем 162 файла (и это еще даже не половина). В девелоперском окружении все подключается с помощью requirejs, и, знаете — получается быстрее, чем работает сборщик на grunt'е.
                            0
                            Но проблема не только в этом, а в том, что дебажить ЭТО — сущий кошмар.

                            там есть два режима сборки, обычный и production. Так вот в production все сжимаеться, а в обычном у вас нормальный JavaScript код, который нормально дебажиться.
                              +1
                              Да, но если все слито в один скрипт длинной 20 тысяч строк, то все равно это дебажить нереально.
                        +3
                        увидел логотип, дальше не читал.
                          0
                          Ой, да ладно — у nginx`а вон тоже его вообще не было, а основной сайт до сих пор не образец дизайну. И чо?

                          Хотя черепаха пугает :)
                            0
                            Я так понимаю TortoiseSVN вы тоже не используете ;)
                            0
                            ТС, сложно баги на гитхаб скинуть?

                            Меня больше пугает отсутствие доков на github.com/itherz/NikaFramework

                            Плюс история коммитов github.com/itherz/NikaFramework/commits/master — ниччо не ясно — что делалось, зачем делалось?
                              0
                              дока (пока что) — nikaframework.com/docs/nutshell/
                              баги лучше кидать на JIRA — bugs.nikaframework.com/
                              на счет коммитов согласен. Нужно писать нормальные комменты
                                0
                                Custom Jira? НЕНАВСИТЬ!

                                bugs.nikaframework.com/secure/Dashboard.jspa

                                Зарегиться где-то там? Неет!

                                Я уже, да не я — мы все на гитхабе сидим и у него есть issue`и. Давайте уж там тада.

                                Плюс для него даже для эклипса есть mylyn-коннектор — во как уже товарищи продвинулись.
                                  0
                                  Про доки — то, что скинуто — это что-то подробное.

                                  Возможно чуть менее подробно и в README.md — будет само то.

                                  Лицензия какая?
                                    0
                                    Сделаем. Лицензия MIT

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое