Клиент-сервер в вебе
Задача
Есть задача — создать панель администрирования баннерных мест на сайтах. Для начала я сделал стандартное Zend приложение, ну MVC все дела, естественно.
Чуть позже задумался над интерфейсом(самопал на jQuery, во-первых, не всегда удобен, во-вторых, не централизован, то есть в одном месте реализована одна таблица, в другом месте вообще всё на выпадающих меню, кроме того практика писать для каждой страницы свой .js файл абсолютно не учитывает повторяемость кода), а всё потому что нет единой библиотеки интерфейса и, создавая одну панель, я естественно думал о том, чтобы она была удобной и понятной, но в итоге поучилось расслоение.
Поиск
Сразу было решено сделать для админки JS библиотеку интерфейса, тоесть объединить часто используемые виджеты, чтобы исключить повторяемость кода.
При попытке сделать это, появилась иная проблема: часто подключаемые файлы созданных виджетов(их порядка 6-8 js и 3-5 css) увеличивали время загрузки страницы до 2х секунд, что не есть гуд.
Просидев вечер над оптимизацией, решил посмотреть на ExtJS. Покопался с лицензией и отказался от этого варианта, так как не собирался открывать сорсы, и платить тоже не хотелось, зато для себя черпнул вдохновения, и решил, что для админки, интерфейс — отдельное приложение, взаимодействующее с сервером методом AJAX запросов.
Плюсы такого подхода:
Выбор средств.
Для себя уяснив архитектуру, я начал выбирать библиотеки для реализации своей идеи. jQuery сразу сдала, ибо предоставляла не все необходимые мне средства. ExtJs провалился с лицензией. QooxDoo продержался дольше, но увы питон для программирования GUI мне не понравился, и я пошел дальше, на более низкий уровень. Глянул на YUI и понял что это не то, а вот Google Closure Library впечатлил меня сразу.Мало того, что есть всё, что нужно, так ещё и Closure Complier, и сборка зависимостей в один файл… В общем всё то, что я искал, при том искаропки. В общем всё то что я искал, при том искаропки.
Решение
Выбрав средства для реализации, я начал продумывать архитектуру.
Создание множества страниц с набором функций противоречит изначальной цели — мы приходим к тому от чего отправлялись.
Поэтому на данный момент я выбрал структуру WebDesktop, но в облегчённой версии. Тоесть у нас нет перехода к стандартному десктопу, вместо этого мы создаём меню откуда вызываем окна, с нашими страницами.Конечно, такая структура будет заметно дольше грузится и не стандартна для веба, зато в итоге мы получаем панельку в едином стиле, и загружается она 1 раз, после чего полностью интерактивна.
Есть задача — создать панель администрирования баннерных мест на сайтах. Для начала я сделал стандартное Zend приложение, ну MVC все дела, естественно.
Чуть позже задумался над интерфейсом(самопал на jQuery, во-первых, не всегда удобен, во-вторых, не централизован, то есть в одном месте реализована одна таблица, в другом месте вообще всё на выпадающих меню, кроме того практика писать для каждой страницы свой .js файл абсолютно не учитывает повторяемость кода), а всё потому что нет единой библиотеки интерфейса и, создавая одну панель, я естественно думал о том, чтобы она была удобной и понятной, но в итоге поучилось расслоение.
Поиск
Сразу было решено сделать для админки JS библиотеку интерфейса, тоесть объединить часто используемые виджеты, чтобы исключить повторяемость кода.
При попытке сделать это, появилась иная проблема: часто подключаемые файлы созданных виджетов(их порядка 6-8 js и 3-5 css) увеличивали время загрузки страницы до 2х секунд, что не есть гуд.
Просидев вечер над оптимизацией, решил посмотреть на ExtJS. Покопался с лицензией и отказался от этого варианта, так как не собирался открывать сорсы, и платить тоже не хотелось, зато для себя черпнул вдохновения, и решил, что для админки, интерфейс — отдельное приложение, взаимодействующее с сервером методом AJAX запросов.
Плюсы такого подхода:
- Приближение к десктопным приложениям.
- Более понятная для новичка реализация интерфейса.
- Более удобное взаимодействие с пользователем.
- Больше динамики.
Выбор средств.
Для себя уяснив архитектуру, я начал выбирать библиотеки для реализации своей идеи. jQuery сразу сдала, ибо предоставляла не все необходимые мне средства. ExtJs провалился с лицензией. QooxDoo продержался дольше, но увы питон для программирования GUI мне не понравился, и я пошел дальше, на более низкий уровень. Глянул на YUI и понял что это не то, а вот Google Closure Library впечатлил меня сразу.Мало того, что есть всё, что нужно, так ещё и Closure Complier, и сборка зависимостей в один файл… В общем всё то, что я искал, при том искаропки. В общем всё то что я искал, при том искаропки.
Решение
Выбрав средства для реализации, я начал продумывать архитектуру.
Создание множества страниц с набором функций противоречит изначальной цели — мы приходим к тому от чего отправлялись.
Поэтому на данный момент я выбрал структуру WebDesktop, но в облегчённой версии. Тоесть у нас нет перехода к стандартному десктопу, вместо этого мы создаём меню откуда вызываем окна, с нашими страницами.Конечно, такая структура будет заметно дольше грузится и не стандартна для веба, зато в итоге мы получаем панельку в едином стиле, и загружается она 1 раз, после чего полностью интерактивна.
0 комментариев