Проблема структурирования JavaScript (разделение логики представления и модели)

Question

Я работаю над Javascript-частью (использующей jQuery) для веб-сайта (в данный момент я работаю над созданием прототипа).

Чтобы подвести итог, что я делаю,У меня есть серия «икон».Каждая иконка на данный момент является изображением.У меня также есть серия «ведер».Все значки начинаются в одном ведре.Пользователь может создавать новые сегменты и перетаскивать значки из одного сегмента в другой.Иконки также можно включать и выключать, нажимая на них (хотя они все еще остаются в их корзине).

У меня все работает в данный момент все нормально, однако на данный момент это в основном куча элементов imgпереходя от div к div.Когда я буду готов приступить к реализации логики на стороне сервера, мне понадобится способ сообщить, что происходит с сервером.

Мне нужен объект-модель, отражающий происходящее.с видом.Было бы хорошо, если бы пользователь был готов отправить данные обратно на сервер, у меня был бы объект, который я мог бы сериализовать, представляющий то, что мне нужно.Например, если пользователь перетащил значок email.png в корзину «Параметры», я бы хотел, чтобы это было отражено в объекте модели (т. Е. {'Options': ['email']}).

Проблема в том, что вся моя логика основана на событиях.Когда пользователь перетаскивает значок в элемент div, на элемент img DOM запускается событие, из-за которого я не уверен, как получить доступ к его модели для его обновления.Единственное, о чем я могу думать, - это синтаксический анализ img src и использование его для определения названия опции модели, но это очень хакерское и не элегантное решение.

Есть идеи?

Answer 1

Можно ли использовать идентификатор элемента или атрибут класса для хранения имени модели?Затем вы можете указать любую строку для каждого, вместо того, чтобы пытаться отключить атрибут src.

Answer 2

Вы можете просто оставить значки в корзинах, а затем спросить, что в них, когда вам нужно поговорить с сервером. Пока значки имеют какой-то уникальный атрибут (например, id) для их идентификации, вы можете по мере необходимости строить свою модель на лету. Нечто подобное можно использовать для сериализации ваших контейнеров:

http://jsfiddle.net/ambiguous/3ufhn/

Это будет хорошо работать, пока все будет просто. Если все станет сложнее, то явная установка MVC облегчит задачу, и подход Джона К .data пригодится; Вы также можете использовать <form> со скрытыми входами для отслеживания вашего состояния.

Answer 3

Вы можете поддерживать необработанную объектную модель или граф объектов, присоединяя корневой объект к чему-либо в DOM или, альтернативно, используя систему данных jQuery , чтобы сохранить ее.

Дажессылаться на элементы DOM вашего пользовательского интерфейса в этой централизованной модели, чтобы уменьшить сложность двух разных моделей.

Для jQuery плагинов весьма характерно централизовать состояние так, как вы ищете, внутри системы данных jQuery.

raw JavaScript

document['myObjectGraph'] = {
    first: 1,
    second: 'two,
    images: [
        document.getElementById('img1'),
        document.getElementById('img2')
    ],
    items: [
        'a',
        'b',
        another = { /* building out the model...*/ };
    ] 
};

или система данных jQuery (та же идея)

jQuery.data(document.body, 'myObjectGraph', {
    first: 1,
    second: 'two,
    images: [
        $('#img1'),
        $('#img2')
    ],
    items: [
        'a',
        'b',
        another = { /* building out the model...*/ };
    ]         
});

Фактически это создает управляемую модель в одном месте (которую вы выбираете для дизайна) - она ​​представляет состояние ваших значков, сегментов и всего остального;его можно сериализовать с помощью JSON и отправить на сервер с помощью вызова ajax ;и ваши элементы пользовательского интерфейса могут даже быть перестроены / обновлены из него.

Эта идея связана с затратами на дополнительное косвенное обращение и усилия по синхронизации исходной модели с моделью пользовательского интерфейса.