// и все это объедененно в компонент начиная от сюда
let inputModel = {value: null};
let inputView = document.querySelector('.some-inpur');
function controller(){
inputView.addEventListener('change', event => inputModel.value = event.data);
}
// и заканчивая здесьclass SomeInput {
private _input;
private _data: string;
public get data(): string {
return this._data;
}
constructor(){
this._input = document.createElement('input');
this._input.addEventListener('change', this.input_changeHandler);
document.body.appendChild(this._input);
}
protected input_changeHandler = (event) => {
this._data = event.data;
}
}let gameField = [
0, 1, 0, 0,
0, 0, 0, 0,
0, 0, 1, 0
];Так что еще раз повторюсь, в чем проблема?
вот вы хороший пример писали про морской боль. И мы же вроде как обсуждали только модель, само приложение, никакого графического интерфейса - только логика игры, модель системы. И вот у нас уже откуда-то вылезло mvvm и т.д.
Но может быть такая ситуация, когда второстепенной модели может потребоваться обратится к модели приложения. Вот тогда бы я мог сказать что такой подход можно назвать mvvm, но только как подход, когда модель обращается к другой модели
вот в этом и проблема, у нас нет двух моделей. Модель всего одна.
Маленький пример - у меня есть тест. Его модель содержит коллекцию, которая содержит узлы с полем index. Сам тест заключается в анализе последовательности индексов.
Это модель из mvc.
Еще раз, Вы не понимаете что такое модель, так как сказали что модели две. Модель всего одна, второй модели с точки зрения приложения не существует, она всего-лишь представление, которое зависит от модели.
она всего-лишь представление, которое зависит от модели. Но на деле это представление настолько сложное что нуждается в собственной моделе.
Представление запросит картинки, а какие картинки - решает модель. То что вы описали (подсовывание контента исходя из каких-то бизнес правил) это именно бизнес логика, а не логика представления.
Представление не может запрашивать данные с сервера, оно может только попросить модель что-то предоставить, а уже как это делает модель - не имеет значения в контексте вопроса.
состояние это информационная модель, которая отношения к бизнес модели не имеет.
Это была первая часть. С чем Вы не согласны?
Но это представление состояния данных именно в контексте бизнес модели и фактически это является деталью ее реализации. К View в MVC это не имеет никакого отношения (просто уточняю).
Раз уж мы говорим о картинках, что же делать если картинки это часть домена?
Или это все часть View?
Модель может содержать названия тех операций, которые необходимы провести с картинкой, если это необходимо по логике.
Если рассматривать на примере тостера, то есть BaseView, в которую вложено ещё три LeftSideView, CenterView и LeftView. А вот уже они собирают в себе компоненты, которые к mvc вообще никакого отношения не имеют, они просто компоненты.
<toster-sidebar>
<profile></profile>
<navigation></navigation>
<notifications></notifications>
</toster-sidebar>Это на самом деле не столь важная тема, важно именно отделение логики обработки данных от презентационной логики, и в вашей и в моей системе координат это отделение происходит, и только это важно.
Смотрите сквозь призму человека, который пишет на языке где и отображение и логика и все остальное это один единственный язык.
Все компоненты идут из коробки и уже имеют то что Вы все хотите вынести в model.
Это по Вашему кнопка состоит из html === view, js === model и controller === js и все это вместе компонент.
А у автора mvc компонент это сама кнопка.
Вы сто раз сказали что я говорю ерунду, но Вы не хотите слышать что компонент это кнопка, это инпут. Вы не хотите понять что представление это очень сложное "творение" которое даже может превзойти по сложности инициализации все приложение вместе взятое.
А у автора mvc компонент это сама кнопка
То есть в случае с фронтэндом активная вьюшка это что-то что формирует DOM (при помощи шаблонизаторов, или просто руками).
Вы выносите данные в отдельный объект, Вы разносите логику для работы с данными в разные сервисы, Вы делаете все чтобы построить взаимосвязь этих частей без жесткой связанности.. Но это все равно не mvc и даже не дальний родственник.
Представление это все что составляет не бизнес логику.
Именно! Я где-то говорил что это имеет хоть какое-то отношение к MVC?
не не не, сам компонент это не MVC, это только VC (контроллер либо как медиатор либо как активная вьюшка в случае презентеров и вью модель).
И вот я кажется понял корень недопонимания, хотя немного не уверен. Для вас база данных это представление?
Компонент это то что можно уже включить и оно будет работать.
То что использует представление и не является бизнес логикой и есть логика представления и его данные, которые я называю ассетами.
База это просто хранилище, обычное, так же как и хранили данных на уровне кода, как например vo.
Вы выносите данные в отдельный объект, Вы разносите логику для работы с данными в разные сервисы, Вы делаете все чтобы построить взаимосвязь этих частей без жесткой связанности.. Но это все равно не mvc и даже не дальний родственник.
Именно! Я где-то говорил что это имеет хоть какое-то отношение к MVC? Я как раз таки хотел сконцентрировать внимание что приложение это обычно чуть по сложнее чем тупо модель.
Приложение имеет одно представление данных, одну модель, а граффический интерфейс отображает ментальную модель пользователя.
И важно понимать зачем это надо, а не как это реализуется в частном случае.
а что такое "одно представление данных"?
Ведь есть же ещё ViewModel, которые снесут мозг тем кто не сможет с этим шагом разобраться.
print ("The answer is: " + 42) # Ошибка, нужно явно кастить к строкеНо у ECS все же своя сфера применения.
