M>>Блин. Еще один. Тебе провести урок HTML 101, рассказывающий, как и каким образом можно порушить любую верстку совершенно валидным маркапом? WH>Мамут такой мамут. WH>Вместо того чтобы признать что из-за незнания сморозил глупость начал дальше вертеться.
Вертишься тут только ты с Владом
WH>А то, что можно написать код, который делает не то что нужно в этом никто не сомневается.
Угу. Когда программисты, никогда ничего не делавшие внятного для веба, начинают рассказывать «а, ничего, потом дизайнеры CSS-ом подправят», таких программистов надо отправлять пилить что-нибудь другое, а не веб.
WH>>>Ну и попробуй понять разницу между серверным шаблонным движком коих тьма. WH>>>И клиентским MVVM которым является Nemerle.Web. M>>Ты можешь повторять эту мантру сколько угодно. Но до тех пор пока для малейших изменений необходимо, чтобы программист правил HTML-код, движок можно закапывать. WH>Покажи мне движок, который может то же самое что и Nemerle.Web и там не нужно править код. WH>Вот, например http://learn.knockoutjs.com/#/?tutorial=intro WH>Там тоже приходится код внутри HTML писать.
«Внутри» надо писать два с половиной байндинга, а не говнокодить захардкоженный HTML внутри кода приложения.
WH>>>А что он будет делать с любым другим фреймворком? Пилить жабаскрипт? M>>Он возьмет HTML в шаблоне и поправит HTML. WH>И что ему помешает взять и поправить исходник?
Зачем дизайнеру ставить студию и компилировать эти исходники? Более того, еще и разбираться в Немерле-коде, чтобы что-то не напортачить?
Самый простейший пример я уже привел. Заменить отображение «ищется» на спиннер внутри поискового поля или на самой кнопке. Покажи, как это будет сделано на мега-вебфреймворке, который «ах-ах-ах является способом создания динамического GUI».
M>>Это уже меньше мешает верстальщику. Более того, верстальщик может менять дизайн/верстку, не ожидая, пока это сподобится за него сделать программист. M>>Я имел в виду, что, по сути, для каждого телодвижения надо привлекать программиста, чтобы он правил HTML-код. Тебе не кажется, что HTML-код должен править верстальщик?
_NN>Не совсем понимаю. _NN>У нас есть логика представления, скажем, показывать или не показывать <div>. _NN>Это зависит от какой-нибудь переменной , скажем X. _NN>Завтра она меняется на Y или ну другую логику, и "надо привлекать программиста".
В большинстве случаев не надо. Для тех простых вещей, из-за которых тебе придется постоянно привлекать программиста — не надо.
_NN>Давай более развернутый пример. _NN>Что было, как мы хотим это изменить, и каким образом не нужен программист.
_NN>Не совсем понимаю. _NN>У нас есть логика представления, скажем, показывать или не показывать <div>. _NN>Это зависит от какой-нибудь переменной , скажем X. _NN>Завтра она меняется на Y или ну другую логику, и "надо привлекать программиста".
_NN>Давай более развернутый пример. _NN>Что было, как мы хотим это изменить, и каким образом не нужен программист.
Для этого нужен программист, а для правки ХТМЛ и стилей нужен верстальщик и ему удобнее оперировать голым ХТМЛ и ЦСС.
Задача хорошего шаблонного движка сделать так, чтобы они
1) правили разные файлы
2) верстальщику не нужно компилировать и перезапускать приложение
3) в супер-супер идеале верстальщику не нужно запускать приложение, а нужно просто открыть хтмл в броузере.
Примерно такой подход реализован в Викете, хотя по 2 и 3 пунктам там не всё всегда гладко. Но главная проблема там, что связывание идет через string id, которые, естественно, не компайл-сэйф. Вот тут и есть простор для НемерлеВеб, который мог бы проверять такое связывание в компайл-тайм. Но если я правильно понимаю, то система макросов в Немерле такое не потянет, поэтому вы пишете просто "ещё один движок", который в чём-то лучше, в чём-то такой же, в чём-то хуже остальных.
Здравствуйте, Mamut, Вы писали:
M>«Внутри» надо писать два с половиной байндинга, а не говнокодить захардкоженный HTML внутри кода приложения.
Понятно. Писать код на жабоскрипте дизайнерам можно.
На немерле нет.
Я тебя правильно понял?
M>Зачем дизайнеру ставить студию и компилировать эти исходники? Более того, еще и разбираться в Немерле-коде, чтобы что-то не напортачить?
А зачем дизайнеру ставить knockoutjs, разбираться в коде на жабоскрипте чтобы что-то не напортачить?
M>Самый простейший пример я уже привел. Заменить отображение «ищется» на спиннер внутри поискового поля или на самой кнопке. Покажи, как это будет сделано на мега-вебфреймворке, который «ах-ах-ах является способом создания динамического GUI».
Примерно так же как на knockoutjs.
Только код будет намного чище. Без всякого уродства типа ko.observable. И компилятор проследит, что все закрывающие теги на месте и нет опечаток в биндингах.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>«Внутри» надо писать два с половиной байндинга, а не говнокодить захардкоженный HTML внутри кода приложения. WH>Понятно. Писать код на жабоскрипте дизайнерам можно. WH>На немерле нет. WH>Я тебя правильно понял?
Нет, неправильно. Максимум, что надо выучить — язык шаблона и пару специфических аттрибутов типа data-bind
M>>Зачем дизайнеру ставить студию и компилировать эти исходники? Более того, еще и разбираться в Немерле-коде, чтобы что-то не напортачить? WH>А зачем дизайнеру ставить knockoutjs, разбираться в коде на жабоскрипте чтобы что-то не напортачить?
Ему его не надо ставить, и разбираться в коде яваскрипта не надо.
M>>Самый простейший пример я уже привел. Заменить отображение «ищется» на спиннер внутри поискового поля или на самой кнопке. Покажи, как это будет сделано на мега-вебфреймворке, который «ах-ах-ах является способом создания динамического GUI». WH>Примерно так же как на knockoutjs. WH>Только код будет намного чище. Без всякого уродства типа ko.observable. И компилятор проследит, что все закрывающие теги на месте и нет опечаток в биндингах.
Да-да. Будет только захардкоженый HTML, который будет править программист, ага
Еще раз, для улучшения библиотеки хочется понять как это должно быть, чтобы не "менять код".
Не просто словами, а примерами.
Вот сейчас делается так, а должно быть эдак.
Здравствуйте, avpavlov, Вы писали:
A>Для этого нужен программист, а для правки ХТМЛ и стилей нужен верстальщик и ему удобнее оперировать голым ХТМЛ и ЦСС. A>Задача хорошего шаблонного движка сделать так, чтобы они
A>1) правили разные файлы
Пункт 1 как я уже сказал, сделать совсем несложно. Как будет время сделаем, не стоит зацикливаться.
A>2) верстальщику не нужно компилировать и перезапускать приложение A>3) в супер-супер идеале верстальщику не нужно запускать приложение, а нужно просто открыть хтмл в броузере.
Т.е. на лету считывать файлы и генерировать представление для клиента ?
Это уже посложнее, но думаю не так сложно сделать.
A>Примерно такой подход реализован в Викете, хотя по 2 и 3 пунктам там не всё всегда гладко. Но главная проблема там, что связывание идет через string id, которые, естественно, не компайл-сэйф. Вот тут и есть простор для НемерлеВеб, который мог бы проверять такое связывание в компайл-тайм. Но если я правильно понимаю, то система макросов в Немерле такое не потянет, поэтому вы пишете просто "ещё один движок", который в чём-то лучше, в чём-то такой же, в чём-то хуже остальных.
Тут вообще ничего не понял, что за строковые идентификаторы и как их едят, а главное зачем они нужны.
Здравствуйте, Mamut, Вы писали:
M>Нет, неправильно. Максимум, что надо выучить — язык шаблона и пару специфических аттрибутов типа data-bind
И что же нужно выучить в Nemerle.Web кроме "язык шаблона и пару специфических аттрибутов типа data-bind"?
Неужели то, что шаблон лежит в методе View?
Это же просто ужасно сложно.
Ни один верстальщик это никогда в жизни не сможет.
M>Ему его не надо ставить, и разбираться в коде яваскрипта не надо.
Ага. Ага.
Ты хочешь сказать, что ViewModel будет каждый раз править программист?
M>Да-да. Будет только захардкоженый HTML, который будет править программист, ага
Чем он более захардкожен чем в knockoutjs?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Дерево для rsdn.ru созданнео на NemerleWeb
A>>2) верстальщику не нужно компилировать и перезапускать приложение A>>3) в супер-супер идеале верстальщику не нужно запускать приложение, а нужно просто открыть хтмл в броузере. _NN>Т.е. на лету считывать файлы и генерировать представление для клиента ? _NN>Это уже посложнее, но думаю не так сложно сделать.
Если планируется разделение на ХТМЛ файл и прочее, то непонятно какие проблемы с "считывать и генерировать". Файл просто как ресурс идет
A>>Примерно такой подход реализован в Викете, хотя по 2 и 3 пунктам там не всё всегда гладко. Но главная проблема там, что связывание идет через string id, которые, естественно, не компайл-сэйф. Вот тут и есть простор для НемерлеВеб, который мог бы проверять такое связывание в компайл-тайм. Но если я правильно понимаю, то система макросов в Немерле такое не потянет, поэтому вы пишете просто "ещё один движок", который в чём-то лучше, в чём-то такой же, в чём-то хуже остальных. _NN>Тут вообще ничего не понял, что за строковые идентификаторы и как их едят, а главное зачем они нужны.
Они не нужны Как я уже сказал, они являются проблемой Викета.
Нафига это в шаблоне? Что такое css-is-active? Что за невнятные и непонятные расширения HTMLя?
1. Вынести это в отдельный файл (верстальщику/дизайнеру вообще даром не упал ни Nemerle, ни студия, ни компиляция)
2. Свести как можно ближе к стандартному HTMLю. Всякое css-is-active, attr-src, css-pinned, style-margin-left, attr-href, css-with-children, css-selected-search-result — в топку.
3. Убрать всю императивщину из HTMLя нафиг (MainPage.Instance.IsActiveNode? Вы с дуба рухнули?). И вообще протягивать внутрь представления вообще всю логику, что реализована в Nemerle — тоже в топку.
4. В шаблон передается ограниченный набор переменных и ограниченный набор инструментов манипуляции с ними, которые легко понять и легко выучить, и с которыми верстальщик может играться как ему угодно. Что-то типа <span class="node-caption {% if active_node == node %} node-active {% endif %}" >
_NN>Еще раз, для улучшения библиотеки хочется понять как это должно быть, чтобы не "менять код". _NN>Не просто словами, а примерами. _NN>Вот сейчас делается так, а должно быть эдак.
Это можно и саму. Можно просто откинуться, взять цитаты
Отдавать разработку таких вьюх дизайнерам имеет мыло смысла. Им лучше отдавать настройку css-а, с помощью которого они смогут управлять внешним видом UI.
Смогут ли они управлять внешним видом UI только с помощью CSS-а, получая произвольный код от программистов? Если нет (а ответ: нет, конечно), то надо давать возможность править HTML максимально безболезненно
если человек хотя бы немножечко программист, то можно просто дать ему доступ к проекту. Пусть правит вьюхи прямо в нем и смотрит на результат.
вместо гор плохо читаемого кода создавался бы простой и ясный код модели + коротенькие представление использующие парадигму биндинга для отображения данных очень шаблонную систему для динамического рендеренга ХТМЛ-я
Ни один «немножечко программист» эти вьюхи не осилит, потому что они наугад вносят какие-то расширения к HTMLю, которые берутся неизвестно откуда. Соответсвенно, надо упрощать, смотреть, как это делается в других шаблонных движках.
Здравствуйте, Mamut, Вы писали:
M> Нафига это в шаблоне? Что такое css-is-active? Что за невнятные и непонятные расширения HTMLя?
Будет документация, будет внятно.
M>2. Свести как можно ближе к стандартному HTMLю. Всякое css-is-active, attr-src, css-pinned, style-margin-left, attr-href, css-with-children, css-selected-search-result — в топку.
Примеры из AngularJS:
Я понимаю это не считается "стандартным" HTML ?
M>Ни один «немножечко программист» эти вьюхи не осилит, потому что они наугад вносят какие-то расширения к HTMLю, которые берутся неизвестно откуда. Соответсвенно, надо упрощать, смотреть, как это делается в других шаблонных движках.
Пожалуйста :
Здравствуйте, avpavlov, Вы писали:
A>Если планируется разделение на ХТМЛ файл и прочее, то непонятно какие проблемы с "считывать и генерировать". Файл просто как ресурс идет
Будет видно что и как.
Может хотите помочь проекту ? выглядит на бумаге довольно просто для такой мегафичи
A>Они не нужны Как я уже сказал, они являются проблемой Викета. A>http://wicket.apache.org/learn/examples/guestbook.html
Столько кода для простых вещей, как я люблю Java подход
Здравствуйте, _NN_, Вы писали:
_NN>Я понимаю просто иметь спец. атрибут, чтобы не генерировать биндинги и вставить "как есть" ? _NN>Этого достаточно ?
Что значит "как есть"? Значение переменных по прежнему нужно будет подставлять и раскручивать (т.е. нужен ренедеринг). Но вот биндинг на сервере не нужен уже. Плюс я должен иметь возможность на сервере перехватить факт открытия страницы и срендерить ее содержимое. В общем, как в Разоре.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Поскольку в таком случае ни исключать форумы ни оставлять только их смысла нет, то смысл в доп. контроле остается только для того, чтобы искать проекты и файлы. Сдается мне, что эти сценарии настолько редко используемы, что необходимость держать ради них в дереве специальный механизм довольно сомнительна. Ведь есть поиск, лучше вынести в него. Вообще проекты это не то, на что стоит делать ставку рсдн, но это уже офтопик.
Ну, может быть.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
M>> Нафига это в шаблоне? Что такое css-is-active? Что за невнятные и непонятные расширения HTMLя? _NN>Будет документация, будет внятно.
M>>2. Свести как можно ближе к стандартному HTMLю. Всякое css-is-active, attr-src, css-pinned, style-margin-left, attr-href, css-with-children, css-selected-search-result — в топку. _NN>Примеры из AngularJS: _NN>
M>>Ему его не надо ставить, и разбираться в коде яваскрипта не надо. WH>Ага. Ага. WH>Ты хочешь сказать, что ViewModel будет каждый раз править программист?
С вашими подходами ничего другого не остается.
M>>Да-да. Будет только захардкоженый HTML, который будет править программист, ага WH>Чем он более захардкожен чем в knockoutjs?
В knockout-js в коде шаблона в идеале вообще не будет яваскрипта. В вашем сверхсупермегафреймворке уже внезапно
M>> Нафига это в шаблоне? Что такое css-is-active? Что за невнятные и непонятные расширения HTMLя? _NN>Будет документация, будет внятно.
Нет, не будет. Принципиально неверный подход. В том месте, где knockout предлагает байндинг к данным, не затрагивая основных подходов HTMLя, вы переопределяете половину аттрибутов и CSS ради чего? Да ни ради чего.
Вот зачем на пустом месте огород городить? Кто там говорил про «дизайнеру надо будет только CSS поправить». Если для того, чтобы понять, какой CSS там нагенерится, ему надо прочитать талмуд по «вот вам точно такие же, как в CSS, но совершенно другие аттрибуты», нафиг такой фреймворк нужен?
Это я не говорю об абсолютно непонятном scope контрольных инструкций $when, $foreach и т.п.
Здравствуйте, Mamut, Вы писали:
WH>>Ты хочешь сказать, что ViewModel будет каждый раз править программист? M>С вашими подходами ничего другого не остается.
А что в knockoutjs иначе?
Если верстальщик захочет связать пару элементов, то ему придется лезть в жабаскрипт.
M>В knockout-js в коде шаблона в идеале вообще не будет яваскрипта. В вашем сверхсупермегафреймворке уже внезапно
Ты действительно не понимаешь, что это всё можно засунуть во ViewModel?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>>>Ты хочешь сказать, что ViewModel будет каждый раз править программист? M>>С вашими подходами ничего другого не остается. WH>А что в knockoutjs иначе? WH>Если верстальщик захочет связать пару элементов, то ему придется лезть в жабаскрипт.
Скорее всего не придется.
M>>В knockout-js в коде шаблона в идеале вообще не будет яваскрипта. В вашем сверхсупермегафреймворке уже внезапно WH>Ты действительно не понимаешь, что это всё можно засунуть во ViewModel?
Засовывайте Пока не засунули, все разговоры о мегакрутизне идут лесом