Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Аноним, Вы писали:

А>>Сформулируй что должен сделать алгоритм. Либо я не правильно понял либо я его напишу.

VD>Что такое атрибутная грамматика знаешь?
Знаю. О чем ты теперь понял.

Здравствуйте, VladD2, Вы писали:

I>>Имхо ты преувеличиваешь сложность связей.
VD>Из чего такой вывод? Сложны они в компиляторе. В MVVM они просты.
Я про это и говорю.

VD>1. Связи идут в обе стороны.
DOM элемент знает о модели, модель не знает о DOM элементе. Обновление двухстороннее, да.

VD>2. Это не правильный подход, так как DOM понятие аморфное. Нужно рассматривать VM как объект с входами и выходами для связывания.
Тут я не понял о чём ты. DOM — понятие достаточно чёткое.

VD>Предположим у нас есть два свойства. При изменении одного вычисляется другое. Далее мы связываем это другое свойство как источник для текстбокса (при изменении свойства меняется текстбокс). Далее текстбокс подключаем как источник для первого свойства. В итоге мы получаем цикл через "DOM". Сами по себе свойства не зациклены.
Ты тут предлагаешь привязать значение текстбокса к двум разным свойствам. Во первых фреймворк тебе не позволит этого сделать, а во вторых — зачем? У биндинга нет понятий вход/выход. Есть связь элемент-модель. Значения элемента и модели в любой момент времени (кроме обновления) должны быть одинаковыми.

Здравствуйте, Аноним, Вы писали:

А>Сформулируй что должен сделать алгоритм. Либо я не правильно понял либо я его напишу.

У тебя "Дракон" есть (книга Ахо по компиляторам)? Вот там можно найти описание алгоритма для вычисления зацикливания атрибутных грамматик.

Здравствуйте, ionoy, Вы писали:

I>DOM элемент знает о модели, модель не знает о DOM элементе. Обновление двухстороннее, да.

Это не есть гуд.

VD>>2. Это не правильный подход, так как DOM понятие аморфное. Нужно рассматривать VM как объект с входами и выходами для связывания.
I>Тут я не понял о чём ты. DOM — понятие достаточно чёткое.

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

По сему это плохая модель. Но любая VM общается с View у которого должен быть четки биндинг-интерфейс. Тогда его легко проверить статически и легко сгенерирвоать код связывания.


VD>>Предположим у нас есть два свойства. При изменении одного вычисляется другое. Далее мы связываем это другое свойство как источник для текстбокса (при изменении свойства меняется текстбокс). Далее текстбокс подключаем как источник для первого свойства. В итоге мы получаем цикл через "DOM". Сами по себе свойства не зациклены.
I>Ты тут предлагаешь привязать значение текстбокса к двум разным свойствам. Во первых фреймворк тебе не позволит этого сделать, а во вторых — зачем? У биндинга нет понятий вход/выход. Есть связь элемент-модель. Значения элемента и модели в любой момент времени (кроме обновления) должны быть одинаковыми.

У тебя View всегда из примитивов состоят? А как же сложные View вроде гридов или вложенных контролов? У них должна быть своя логика. И эта логика может подразумевать наличие зависимых друг от друга биндингов.

Да и вообще странно было бы рассматривать биндинги только с элементами DOM, а не с более высокоуровневыми сущностями.

Здравствуйте, VladD2, Вы писали:

I>>DOM элемент знает о модели, модель не знает о DOM элементе. Обновление двухстороннее, да.
VD>Это не есть гуд.
То есть ты предлагаешь в модель пихать код биндинга?

VD>>>2. Это не правильный подход, так как DOM понятие аморфное. Нужно рассматривать VM как объект с входами и выходами для связывания.
I>>Тут я не понял о чём ты. DOM — понятие достаточно чёткое.
VD>DOM это почти произвольная иерархия объектов. Почти каждый его элемент может служить как получателем, так и источником сигналов.
Так и есть.

VD>По сему это плохая модель. Но любая VM общается с View у которого должен быть четки биндинг-интерфейс. Тогда его легко проверить статически и легко сгенерирвоать код связывания.
А по-поему, суть MVVM — отвязать модель от представления. Код связывания и так легко генерируется.

VD>У тебя View всегда из примитивов состоят? А как же сложные View вроде гридов или вложенных контролов? У них должна быть своя логика. И эта логика может подразумевать наличие зависимых друг от друга биндингов.
Это реализуется шаблонами.
Вот кусок кода из Samples.n, который рендерит все остальные сэмплы.

<div $foreach(s in AllSamples)>
  <div $when(SelectedSample.Name == s.Name) class="current-sample">
    <div template="$(template(s.Instance, s.TemplateName))"></div>
      <h2>Source</h2>
    <pre class="prettyprint lang-n prettyprinted">$(s.Source)</pre>
  </div>
</div>

Заметь, внутри каждого отдельного сэмпла мы ничего не знаем о Samples.n, т.е. мы можем сделать каждый сэмпл отдельной страницей практически без изменения кода. Если нужна информация из SamplesPage, то можно передать его в конструкторе и биндится к нему. Имхо это самый правильный подход, который не привносит никаких дополнительных сущностей вроде биднингов.

VD>Да и вообще странно было бы рассматривать биндинги только с элементами DOM, а не с более высокоуровневыми сущностями.
По мне так это совершенно не странно. Почему ты, разрабатывая на C# или Nemerle, не реализовал себе биндинги, если они так нужны? Имхо биндинги это очень специфичная вещь, которая нужна как раз для связи между моделью и представлением.

Здравствуйте, ionoy, Вы писали:

I>То есть ты предлагаешь в модель пихать код биндинга?

Я не совсем понимаю что значит "в модель пихать код биндинга".

Биндинги должны быть описаны для контролов. Есть набор предопределенных контролов вроде текстовых полей, комбов и т.е., а есть контролы/вьюхи которые предоставляют более сложную логику. Вот у таких контролов нужно декларировать точки привязки и описывать их взаимосвязь. Ну, и при привыязке к таким точкам внутри вьюх (в которые вложены эти вьюх-контролы) проверять правильность привязок и генерировать код их поддержки (если нужно).

VD>>По сему это плохая модель. Но любая VM общается с View у которого должен быть четки биндинг-интерфейс. Тогда его легко проверить статически и легко сгенерирвоать код связывания.
I>А по-поему, суть MVVM — отвязать модель от представления. Код связывания и так легко генерируется.

Ты как-то странно понимаешь слова "отвязать модель от представления". "Отвязка" и производится путем введения биндинга.

Вот только вопрос что, с чем и как связывать.

VD>>У тебя View всегда из примитивов состоят? А как же сложные View вроде гридов или вложенных контролов? У них должна быть своя логика. И эта логика может подразумевать наличие зависимых друг от друга биндингов.
I>Это реализуется шаблонами.
I>Вот кусок кода из Samples.n, который рендерит все остальные сэмплы.

I>

I><div $foreach(s in AllSamples)>
I>  <div $when(SelectedSample.Name == s.Name) class="current-sample">
I>    <div template="$(template(s.Instance, s.TemplateName))"></div>
I>      <h2>Source</h2>
I>    <pre class="prettyprint lang-n prettyprinted">$(s.Source)</pre>
I>  </div>
I></div>
I>

Шаблоны и выполняют роль контролов. Вопрос только, насколько типизирован интерфейс шаблона?

I>Заметь, внутри каждого отдельного сэмпла мы ничего не знаем о Samples.n, т.е. мы можем сделать каждый сэмпл отдельной страницей практически без изменения кода. Если нужна информация из SamplesPage, то можно передать его в конструкторе и биндится к нему. Имхо это самый правильный подход, который не привносит никаких дополнительных сущностей вроде биднингов.

Эти сущности и позволили бы делать четкую (декларированную) связь.

VD>>Да и вообще странно было бы рассматривать биндинги только с элементами DOM, а не с более высокоуровневыми сущностями.
I>По мне так это совершенно не странно. Почему ты, разрабатывая на C# или Nemerle, не реализовал себе биндинги, если они так нужны? Имхо биндинги это очень специфичная вещь, которая нужна как раз для связи между моделью и представлением.

Первое что хочется заметить — это прочность твоей логики. Какой смысл пытаться обосновывать идеологию своего решения наличием или отсутствием чего-то где-то? Недавно ты так же обосновывал полную ненужность применения реактивной модели тем, что в ASP.NET MVC ее нет, а все ее используют.

Второе — биндинги не нужны сами по себе. Это часть реактивной модели. Если я возьмусь использовать реактивную модель, то нечто вроде биндингов я обязательно ввиду. Возможно они не будут присутствовать как отдельная сущность, а будут выражаться присвоением или именем свойства в неком теге, но они будут.

Здравствуйте, VladD2, Вы писали:

VD>Шаблоны и выполняют роль контролов. Вопрос только, насколько типизирован интерфейс шаблона?
Шаблон это прититив для вставки одной страницы в другую. Типизированы они точно так же как и основная страница.

I>>Заметь, внутри каждого отдельного сэмпла мы ничего не знаем о Samples.n, т.е. мы можем сделать каждый сэмпл отдельной страницей практически без изменения кода. Если нужна информация из SamplesPage, то можно передать его в конструкторе и биндится к нему. Имхо это самый правильный подход, который не привносит никаких дополнительных сущностей вроде биднингов.
VD>Эти сущности и позволили бы делать четкую (декларированную) связь.
То есть ты неявно хочешь дать модели знать, что её сейчас используют в Samples.n? А если я её ещё в 5 разных страницах вставляю? Как по твоему будет выглядеть код для работы с этими биндингами?

I>>По мне так это совершенно не странно. Почему ты, разрабатывая на C# или Nemerle, не реализовал себе биндинги, если они так нужны? Имхо биндинги это очень специфичная вещь, которая нужна как раз для связи между моделью и представлением.
VD>Первое что хочется заметить — это прочность твоей логики. Какой смысл пытаться обосновывать идеологию своего решения наличием или отсутствием чего-то где-то? Недавно ты так же обосновывал полную ненужность применения реактивной модели тем, что в ASP.NET MVC ее нет, а все ее используют.
Если я не ошибаюсь, я нигде не говорил, что реактивная модель не нужна. Более того, ещё когда только появился KnockoutJS я делал на нём сайты и был доволен. Скорее всего я говорил о том, что это не основной инструмент веб разработки, так я и сейчас так считаю. Реактивность нужна далеко не всем и далеко не всегда.

VD>Второе — биндинги не нужны сами по себе. Это часть реактивной модели. Если я возьмусь использовать реактивную модель, то нечто вроде биндингов я обязательно ввиду. Возможно они не будут присутствовать как отдельная сущность, а будут выражаться присвоением или именем свойства в неком теге, но они будут.
Так и у нас биндинги введены на заднем фоне. Но зачем из кода модели указывать на ноду в DOM'е я всё равно не понимаю. Как ты представляешь себе использование этого всего? И главное, какой от этого профит?

Здравствуйте, ionoy, Вы писали:

VD>>Шаблоны и выполняют роль контролов. Вопрос только, насколько типизирован интерфейс шаблона?
I>Шаблон это прититив для вставки одной страницы в другую.

"Прототип"? Не понял написанного.

I>Типизированы они точно так же как и основная страница.

Так они у тебя типизированы или нет?

I>То есть ты неявно хочешь дать модели знать, что её сейчас используют в Samples.n? А если я её ещё в 5 разных страницах вставляю? Как по твоему будет выглядеть код для работы с этими биндингами?

Биндинги это как вилка и розетка. Телевизору не нужно знать, что он вставлен в конкретную розетку. Важно, что он куда-то вставлен и что там есть электричество.

Просто наличие декларации позволяет проверить, что источник и приемник совместимы. В переводе на пример с розеткой мы знаем, что вилка и розетка одного типа, и что в сети поддерживаемое напряжение. Можно конечно просто совать провода прямо в корпус телевизора, но вот гарантии, что он не сгорит нет.

I>Если я не ошибаюсь, я нигде не говорил, что реактивная модель не нужна. Более того, ещё когда только появился KnockoutJS я делал на нём сайты и был доволен. Скорее всего я говорил о том, что это не основной инструмент веб разработки, так я и сейчас так считаю. Реактивность нужна далеко не всем и далеко не всегда.

Я обращаю твое внимание, на то что так просто нельзя мыслит. То что где-то чего-то нет еще не значит, что это не вообще не нужно. Зачастую чего-то нет по бедности или по глупости.

VD>>Второе — биндинги не нужны сами по себе. Это часть реактивной модели. Если я возьмусь использовать реактивную модель, то нечто вроде биндингов я обязательно ввиду. Возможно они не будут присутствовать как отдельная сущность, а будут выражаться присвоением или именем свойства в неком теге, но они будут.
I>Так и у нас биндинги введены на заднем фоне.

Вот именно, что на заднем фоне.

I>Но зачем из кода модели указывать на ноду в DOM'е я всё равно не понимаю.

А я не понимаю откуда ты взял, что я это предлагаю. Я говорю о том, что хорошо бы абстрагировать вьюхи до эдаких черных ящиков с точками связывания.

I>Как ты представляешь себе использование этого всего? И главное, какой от этого профит?

Полный статический контроль и возможность работать на более высоком уровне нежели DOM.

Здравствуйте, VladD2, Вы писали:

VD>"Прототип"? Не понял написанного.
Примитив, а не прототип. Да и то, не примитив, а скорее вид биндинга.

I>>Типизированы они точно так же как и основная страница.
VD>Так они у тебя типизированы или нет?
Конечно. Только почему-то интеллисенс не работает, видимо нужна твоя помощь. Ошибки подчёркивает и показывает корректно.

...

Посмотри, если будет время, как там сейчас сделано. Вьюх, как отдельных сущностей у нас пока не намечается, я об этом уже говорил. Хорошо это или плохо, скоро будет видно.

То, что ты предлагаешь, это вроде duck typing для представлений. Мол если есть такие-то свойства, то бинди. Но в таком случае вылезает много новых проблем, например с типами. В представлении же не будешь указывать какого типа должно быть поле Value, которое ты прибиндил к инпуту. Даже если забить на это, то опять же, в чём профит? Обычно шаблон пишется под конкретную модель, так просто удобнее.

Ну и с биндингами я так и не понял, как они помогут в коде? Сейчас вроде всё красиво связано, что ещё нужно? Статический контроль, судя по всему, даст только проверку на зацикливания, но, если честно это не тот аргумент, из-за которого я решусь всё переписывать.

Здравствуйте, ionoy, Вы писали:

I>Конечно. Только почему-то интеллисенс не работает, видимо нужна твоя помощь. Ошибки подчёркивает и показывает корректно.

Что нужно сделать чтобы все это дело собрать?

I>Посмотри, если будет время, как там сейчас сделано. Вьюх, как отдельных сущностей у нас пока не намечается, я об этом уже говорил. Хорошо это или плохо, скоро будет видно.

Вы NemerleWeb на практике где-то использовать собираетесь?

I>То, что ты предлагаешь, это вроде duck typing для представлений. Мол если есть такие-то свойства, то бинди.

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

ЗЫ

В общем, вам нужно попробовать фрэймворк в реальных боевых условиях. Тогда многое станет ясным.

Здравствуйте, VladD2, Вы писали:

VD>Что нужно сделать чтобы все это дело собрать?
Нужно установить ASP.NET MVC 3, вроде как больше ничего.

I>>Посмотри, если будет время, как там сейчас сделано. Вьюх, как отдельных сущностей у нас пока не намечается, я об этом уже говорил. Хорошо это или плохо, скоро будет видно.
VD>Вы NemerleWeb на практике где-то использовать собираетесь?
Да, сейчас обсуждаем детали.

VD>В общем, вам нужно попробовать фрэймворк в реальных боевых условиях. Тогда многое станет ясным.
Именно.

Здравствуйте, ionoy, Вы писали:

I>Страница проекта: http://user1663.netfx45lab.discountasp.net/
Не работает.

Здравствуйте, Аноним, Вы писали:

А>Не работает.
Демо переехало сюда: http://moiety.apphb.com/

Здравствуйте, _NN_, Вы писали:

_NN>Здравствуйте, Аноним, Вы писали:

А>>Не работает.
_NN>Демо переехало сюда: http://moiety.apphb.com/
А чат где?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, _NN_, Вы писали:

_NN>>Здравствуйте, Аноним, Вы писали:

А>>>Не работает.
_NN>>Демо переехало сюда: http://moiety.apphb.com/
А>А чат где?

Вам интересен фреймворк или хотите потрепаться ?
Чат восстановлен.

Здравствуйте, _NN_, Вы писали:

А>>Не работает.
_NN>Демо переехало сюда: http://moiety.apphb.com/

Я же просил сказать мне новый адрес. Сейчас поправлю в теме.

Здравствуйте, ionoy, Вы писали:

I>Страница проекта: http://moiety.apphb.com

Откровенно говоря эти цветочки на фоне как-то не в кассу. Может заменить их на что-то более приличное?

Здравствуйте, ionoy, Вы писали:

I>Страница проекта: http://moiety.apphb.com

В тесте "Loading and saving", после удаления одной из строки во всплывающем окне (при записи) всегда пишется 0 уделенных строк.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, ionoy, Вы писали:

I>>Страница проекта: http://moiety.apphb.com

VD>В тесте "Loading and saving", после удаления одной из строки во всплывающем окне (при записи) всегда пишется 0 уделенных строк.

Не совсем понял проблему.
И браузер какой ?

Здравствуйте, _NN_, Вы писали:

VD>>В тесте "Loading and saving", после удаления одной из строки во всплывающем окне (при записи) всегда пишется 0 уделенных строк.

_NN>Не совсем понял проблему.
_NN>И браузер какой ?

Зайди в этот тест, нажми "Delete" и нажми "Save". Далее внимательно изучи результат.

Помнится ionoy там что-то химичил, но результат получился некрасивым. Надо бы поправить.