шаблоны против создания DOM - высокодинамичный интерфейс - PullRequest
Новая
       6

шаблоны против создания DOM - высокодинамичный интерфейс

1 голос
/ 30 января 2010

Создание браузерной игры Я перешел с PHP на JavaScript, который теперь я также хочу использовать на стороне сервера. Поскольку я собираюсь требовать от пользователей иметь JavaScript в любом случае, я собираюсь широко его использовать. Однако я хочу использовать объектно-ориентированный способ.

Учитывая MVC, модели будут использоваться как на стороне клиента, так и на стороне сервера. Представления используются только на стороне клиента. Интерфейс разделен на несколько частей: главное боковое меню, основное содержимое и некоторые виджеты. Я возьму часть, которую я уже сделал в качестве примера: Меню разделено на три категории с несколькими записями. Каждая запись представляет собой ссылку с прикрепленным действием (например, переключение содержимого). 

// menuview:
var self = new View();
var generalMenu = new MenuCategory('generalmenu')
    .addEntry(new MenuEntry('overview', new Action()))
 .addEntry(new MenuEntry('buildings'))
    .addEntry(new MenuEntry('resources'))
// [..more categories..]
self.toData = function() {
    return {
        id: this.id,
        cat: [generalMenu.toData(), infosMenu.toData(), userMenu.toData()]
    };
};

На данный момент View - это композит с методом toData () для создания данных для анализатора шаблонов (самодельный, простой, но поддерживающий итерацию). И действия привязываются после создания. Я использую jQuery в качестве фреймворка: 

self.show = function(callback) {
    $tpl(this.tpl).parse(this.toData()).lang('main').toHTML(function(html) {
        var el = $(html);
        el.find('a').click(function (e) {
            MenuEntry.actionHandler.execAction(e.target.id);
            return false;
        });
        el.appendTo('#'+self.target);
        callback && callback();
    });
    return this;
};

Я объявил обработчик действий, чтобы избежать итерации по ссылкам.

Мне плохо с этим решением, оно недостаточно гибкое. Я хотел бы рассматривать представление как настоящий compositum, а не с множеством странных зависимостей. Кроме того, я должен повторно проанализировать весь вид, если я изменяю часть. Что ж, в этом примере это не очевидно, потому что меню не изменится во время работы, но другие части интерфейса будут.

Теперь, наконец, вернемся к моему вопросу: есть ли лучшее решение? Как если бы ссылки dom распространялись по представлению, каждый пункт меню имел собственную ссылку и непосредственно прикрепленное действие? Если я больше не использую шаблоны, какую гибкость я теряю?

1 Ответ

1 голос
/ 01 февраля 2010

Я решил обойтись без парсера шаблонов. Каждое представление хранит свой узел и может манипулировать им напрямую, если ему сообщают об обновлении данных.

...