Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

extract: аналог split, но для простых моделей #152

Closed
chestozo opened this Issue Aug 28, 2013 · 18 comments

Comments

Projects
None yet
4 participants
Member

chestozo commented Aug 28, 2013

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

Типичный пример:
есть do модель, которая обновляет какую-то модель и возвращает полностью обновлённую модель.
У такой do модели хочется написать примерно такое:

ns.Model.define('do-model-update', {
    params: {},
    extract: [
        {
            path: '.model', //  вытащить по jpath .model данные и создать...
            id: 'model', // модель model
            params: { ... } // тут всё аналогично split
        }
    ]
})

Обсуждали это с @edoroshenko и он сказал, что не видит пока в этом необходимости.
У нас же уже есть место, где это было бы полезно.
Что думаете вы?

Ещё было обсуждение, как назвать это свойство .extract или .split и несколько человек высказались за .extract.

Contributor

edoroshenko commented Aug 28, 2013

В коде выглядит привлекательно :)

Вопросы на подумать.

  1. А должен ли работать extract для modelCollection?
  2. А должны ли экстрагированные модели становиться подмоделями экстрагирующей (речь конечно же про всё, кроме do-моделей)?

Мне пока видится, что

  1. Да, должен. И это аргумент в пользу extract против split. Типа 2 независимых механизма. Extract - для создания независимых моделей, а split - для наполнения коллекций.
  2. Нет не должны.
Owner

basvasilich commented Aug 28, 2013

Мое мнение что это не надо делать на уровне фреймворка в модели.

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

On 28.08.2013, at 18:21, chestozo notifications@github.com wrote:

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

Типичный пример:
есть do модель, которая обновляет какую-то модель и возвращает полностью обновлённую модель.
У такой do модели хочется написать примерно такое:

ns.Model.define('do-model-update', {
params: {},
extract: [
{
path: '.model', // вытащить по jpath .model данные и создать...
id: 'model', // модель model
params: { ... } // тут всё аналогично split
}
]
})
Обсуждали это с @edoroshenko и он сказал, что не видит пока в этом необходимости.
У нас же уже есть место, где это было бы полезно.
Что думаете вы?

Ещё было обсуждение, как назвать это свойство .extract или .split и несколько человек высказались за .extract.


Reply to this email directly or view it on GitHub.

Contributor

edoroshenko commented Aug 28, 2013

Продолжаем рассуждать. Вопрос №2.
Если данные модели m1 содержат данные для модели m2 и по ним создаётся модель m2, то очевидно, модель m2 должна стать вложенной в m1. И это справедливо даже для случая, если m2 не является коллекцией.
Получаем серьёзное усложнение ns.Model и вместе с ней ns.ModelCollection. Вообще, кстати, не особо представляю, как разруливать эти 2 механизма в ns.ModelCollection.
Пока эта штука кажется жизнеспособной только для do-моделей.

Member

chestozo commented Aug 29, 2013

2 @edoroshenko

  1. Да, должен. Но лазить он должен по собственным данным модели коллекции, а не по данным элементов коллекции.
  2. Думаю, что связь может быть как нужна так и не нужна.
    В случае do моделей она не нужна.
    В случае, когда у тебя какая-то большая составная модель - может и нужна.
    Но, опять же, может быть такие большие модели надо явно разбивать на более мелкие.

2 @basvasilich
Дело в том, что это довольно частое поведение, когда у тебя модифицирующая ручка вернёт актуальную модель. Поэтому и была идея сделать это на уровне framework-а.
Пример, возможно, не самый удачный )

Member

chestozo commented Sep 16, 2013

Мы в очередной раз столкнулись с примером, где это было бы удобно.
Есть фотка, к неё есть лайки.
Это всё возвращается одной ручкой.
Но: если фотка не меняется вообще, то лайки — супердинамическая штука.

Хочется менять лайки и при этом чтобы основная модель "не менялась".
Как это могло бы выглядеть:

ns.Model.define('photo', {
  params: { ... },
  // Это вместо extract
  submodels: [
    {
      id: 'likes',
      jpath: '.somewhere.likes',
      trigger_change: false // change подмодели не должен триггерить change модели
    }
  ]
});

И тогда где-то во view можно написать:

ns.View.define('photo-likes', {
  models: [
    'photo.likes'
  ]
});
Contributor

edoroshenko commented Sep 16, 2013

Прямо для таких задач уже есть механизм subview

Member

chestozo commented Sep 16, 2013

Ну вот смотри:

  • у меня есть несколько view, которые зависят от фотки.
  • когда я поменяю лайки - мне их придётся все перерисовать, хотя только одна из них выводит эти самые лайки.

Расписывать все subview сильно накладно и не хочется завязываться сильно на формат модели.

Contributor

edoroshenko commented Sep 16, 2013

Я бы здесь подумал не в сторону подмоделей, а в сторону гибкой настройки реакции на изменения моделей. У нас сейчас есть другая практика: руками делать view валидным при конкретных изменениях модели. Пока не ясно, на сколько эта практика правильная.

Member

chestozo commented Sep 16, 2013

Вы руками в DOM лезить?
Как это всё сочетается с ns.page.go()

Contributor

edoroshenko commented Sep 16, 2013

нет. Идея в том, что если при изменении я понимаю, что оно не затрагивает вид, я дёргаю спец. метод, который синхронизирует версию вида с версией модели. И при update вид останется нетронутым.

Member

chestozo commented Sep 16, 2013

А что такое "синхронизирует версию вида с версией модели" ?

Member

chestozo commented Sep 16, 2013

Посмотрел на эту синхронизацию:
мне кажется, что так делать не надо, потому что ты в API выносишь какие-то внутренности.

Member

chestozo commented Sep 18, 2013

Или вот такой ещё пример, где это полезно:
есть фотка, какая-то такая: { id: 1, author: 'me', url: '/image/url', albumId: 2 }
есть альбом { id: 2, title: 'album title' }

Есть урл: author/me/image/1.
Я хочу получить помимо фотки альбом и показать его название.
Но: у меня нет album.id.

На сервере в descript я бы мог написать так:

{
  photo: de.call('getPhoto()', {
    after: function(params, context, result) {
      params['album-id'] = result.id;
    }
  }) +1,
  album: de.call('getAlbum()')
}

А потом на клиенте бы разобрал это на 2 модели.

Contributor

edoroshenko commented Sep 19, 2013

Посмотрел на эту синхронизацию:
мне кажется, что так делать не надо, потому что ты в API выносишь какие-то внутренности.

Я в будущем, когда додумаю этот кейс, рассчитываю перенести метод syncWithModel в noscript.
Ещё есть мысли декларативно указывать, на какие изменения модели вид должен реагировать, а на какие не должен.

Contributor

edoroshenko commented Sep 19, 2013

Про кейс с альбомом - я тебя понял. Это продолжение твоей идеи.
Сейчас я тебе предлагаю делать это на твоей стороне. Прежде, чем добавлять такую фичу в noscript, нужно это очень хорошо продумать

Member

chestozo commented Sep 19, 2013

Ну я для того и пишу, чтоб обсудить )
А что делает syncWithModel? Я не помню...

Contributor

edoroshenko commented Sep 19, 2013

Идея в том, что ты подписываешь вид на изменение модели и в обработчике, если случившееся изменение не требует перерисовки модели, возвращаешь виду валидный статус.

Member

chestozo commented Sep 19, 2013

Развесисто будет )

@shirokoff shirokoff closed this Nov 17, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment