, был весьма удивлен мнением некоторых людей, мол "отделять HTML-шаблон от программного кода не дает преимуществ". Главное когда Микрософт наваяли WPF -- отделение шаблона представления от кода -- было супер преимуществом. Ну ладно, речь не об этом.
Суть
И задался таким вопросом: а какая абстракция нужна для разработки Web приложений. Определим шкалу от "0" до "100":
— на "0" будет полнейшая смесь html кода -- грубо говоря, склеиваем HTML из отдельных констант и вставляем динамическое содержимое.
— на отметке "100" будет некий свой язык разметки (типа XAML) с серверными событиями, эмуляцией логики JavaScript с помощью серверного кода (все это дело компилируется (или генерирует в процессе работы) в HTML и JavaScript). Словом -- никакой связи с HTML.
Ежу понятно, что истина где-то по середине, обе крайности для практического использования не пригодны. Как вы считаете, до какой степени нужно абстрагировать процесс Web-разработки? Что вы видите в идеале?
P.S.
Не обсуждаем RIA-приложения, только те которые на выходе выдают клиенту HTML-код.
отделять вообще ничего не имеет особого смысла, а имеет смысл — выделение отдельных граней.
отделение приводит к тому, что потом при решение реальной задачи приходится тратить кучу ресурсов на преоделение настроенных ранее барьеров
например, css — хорошо смотрится, благодаря тому, что его функционал лишь выделен из html-я, а не отделен (всё(значимая часть) что делается через css, можно в один-один сделать прямо в html-аттрибутах)
ps
wpf плох тем, что он отделен(фундаментально огорожен) от c#.
в c# — хрен запишешь один в один wpf-дерево (из-за невозможности объявления имен по месту), а в wpf — хрен запишешь связи.
ззы
твой framework еще хуже, т.к. у тебя html совсем "фундаментально огорожен" от динамической генерации.
Здравствуйте, DarkGray, Вы писали:
DG>твой framework еще хуже, т.к. у тебя html совсем "фундаментально огорожен" от динамической генерации.
Более того, он у него требует феноменальных затрат ресурсов (парсинг, построение DOM, сериализация).
Здравствуйте, fddima, Вы писали:
DG>>твой framework еще хуже, т.к. у тебя html совсем "фундаментально огорожен" от динамической генерации. F> Более того, он у него требует феноменальных затрат ресурсов (парсинг, построение DOM, сериализация).
Бред. Я же сказал -- работает быстрее стандартных jsp-шаблонов. Я его уже использую на реальном сайте и наблюдаю за нагрузкой.
Здравствуйте, 0K, Вы писали:
DG>>ззы DG>>твой framework еще хуже, т.к. у тебя html совсем "фундаментально огорожен" от динамической генерации.
0K>Поясните, пожалуйста. Здается мне, что вы не поняли идеи.
Идея не плохоая, хотя не ты ее первым предожил.
Но исполнение просто безобразно. Императивное манипулирование ДОМ-ом — это задница.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
0K>Поясните, пожалуйста. Здается мне, что вы не поняли идеи.
попробуй прикинуть какое кол-во статического html-я есть в каком-нибудь gmail-е, или хотя бы ozon.ru, или в каком-нибудь конструкторе: cms, движок форума и т.д.
соответственно в таких проектах — задачи вида: дать верстальщику возможность редактировать статический html вообще не стоит.
есть лишь задача — как бы простым способом редактировать динамический html, или другими словами — как из одного места уметь записывать и куски html-я и правила их клонирования и объединения.
ps
static html нужен только в задачах аля "это мой крутой homepage".
Здравствуйте, VladD2, Вы писали:
VD>Идея не плохоая, хотя не ты ее первым предожил.
Ссылки в студию! Прежде чем делать что-то я попытался найти готовое. Не нашел.
VD>Но исполнение просто безобразно. Императивное манипулирование ДОМ-ом — это задница.
Императивный подход, хоть он и не "модный", проще. Именно по этому на практике 90% кода императивного. Он гибок и прост. Кроме того, я могу его абстрагировать и некоторые части задавать декларативно.
Здравствуйте, DarkGray, Вы писали:
DG>попробуй прикинуть какое кол-во статического html-я есть в каком-нибудь gmail-е, или хотя бы ozon.ru, или в каком-нибудь конструкторе: cms, движок форума и т.д.
Вы поняли хоть как оно работает?
DG>соответственно в таких проектах — задачи вида: дать верстальщику возможность редактировать статический html вообще не стоит.
Дизайнер будет редактировать ДИНАМИЧЕСКИЕ ШАБЛОНЫ, а не просто статический HTML. Это моя уникальная и неповторимая разработка, которая через несколько лет завоюет весь мир Web-разработки, только естественно у меня ее украдут и скажут что сами придумали.
DG>есть лишь задача — как бы простым способом редактировать динамический html, или другими словами — как из одного места уметь записывать и куски html-я и правила их клонирования и объединения.
Вы что прикидываетесь? Именно ЭТО я и сделал!!! Именно это и решает мой фреймворк и решает.
DG>static html нужен только в задачах аля "это мой крутой homepage".
Какой статик? Вы что? Мой фреймворк как раз определяет простейшие принципы манипулирования динамическими шаблонами. Собственно он так и называется "Dynamic Template".
Здравствуйте, 0K, Вы писали:
0K>Ссылки в студию! Прежде чем делать что-то я попытался найти готовое. Не нашел.
Ссылку на Lift тебе уже давали. До этого тоже не мало подобных идей было.
VD>>Но исполнение просто безобразно. Императивное манипулирование ДОМ-ом — это задница.
0K>Императивный подход, хоть он и не "модный", проще. Именно по этому на практике 90% кода императивного. Он гибок и прост. Кроме того, я могу его абстрагировать и некоторые части задавать декларативно.
Ну, орел упертый. Других не слушаешь. Так что тратить время на переубеждение тебя смысла нет.
Пилите Шура, пилите. Она злотая (с) Ильф и Петров
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ссылку на Lift тебе уже давали. До этого тоже не мало подобных идей было.
Поясните что общего у этого спагетти с моим фреймворком? Мой фреймворк можно сравнить разве что с ASP.Net, только лишенного его главного недостатка -- излишней абстрагированности.
Фишка в том, что НИКТО еще не высказывал подобной идеи. Хотя бы то, что доступ к элементам происходит по id и работа с документом с помощью быстрого DOM-парсера. А работа со списками (в т.ч. с вложенными) в моем фреймворке заслуживает особого внимания: никто не смог сделать так просто и гибко.
Здравствуйте, 0K, Вы писали:
VD>>Ссылку на Lift тебе уже давали. До этого тоже не мало подобных идей было.
0K>Поясните что общего у этого спагетти с моим фреймворком?
Ты довольно наглый и весьма невежественный человек. От того пояснить тебе что-то очень сложно. Надеюсь, что это по молодости и со временем пройдет.
Я попробую, но боюсь, что попытка будет тщетной.
Общее у вас то, что в шаблонах лежит чистый XML (нет кода), и оба подхода используют идею трансформации имеющегося контента, а не идею вставки кода в шаблон и формирование контента путем выполнения этого кода.
То что для тебя он выглядит как спагетти обусловлено объемом твоих знаний и привычками. Для меня Lift-вый код выглядит очень прилично, а макаронами кажется твой. Lift писали люди с большим опытом и весьма широким кругозором. Они постарались сделать его удобным.
0K>Мой фреймворк можно сравнить разве что с ASP.Net, только лишенного его главного недостатка -- излишней абстрагированности.
Вот с ASP.Net у вас мало общего, на мой взгляд. Или тогда уж и Lift тоже можно сравнивать.
0K>Фишка в том, что НИКТО еще не высказывал подобной идеи.
Очень смешно.
Все что ты придумал — это использовать сто лет известный подход, применяемый в броузерах, но на стороне сервера.
Причем в браузерах прямая манипуляция ДОМ-ом считается очень не продуктивным подходом. Для его облегчения придумали кучу библиотек маскирующих манипуляцию домом под декларативные конструкции, а ты наоборот предлагаешь использовать самый дубовый метод.
0K>Хотя бы то, что доступ к элементам происходит по id и работа с документом с помощью быстрого DOM-парсера. А работа со списками (в т.ч. с вложенными) в моем фреймворке заслуживает особого внимания: никто не смог сделать так просто и гибко.
Просто ты не потрудился изучить чужой опыт.
В прочем, с удовольствием послушал бы про работу со списками. Может и правда у тебя есть что-то интересное.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Общее у вас то, что в шаблонах лежит чистый XML (нет кода), и оба подхода используют идею трансформации имеющегося контента, а не идею вставки кода в шаблон и формирование контента путем выполнения этого кода.
Да, в этом небольшое сходство есть.
Но у меня нет жесткой связи. Нет необходимости (и простой возможности) вставлять HTML-теги в код -- связь только по Id. У Lift мне в глаза сразу бросилась смесь HTML и кода на стороне кода. У меня такого нет.
P.S.
Для оживления атмосферы люблю прибегнуть к "красному словцу".
, был весьма удивлен мнением некоторых людей, мол "отделять HTML-шаблон от программного кода не дает преимуществ". Главное когда Микрософт наваяли WPF -- отделение шаблона представления от кода -- было супер преимуществом. Ну ладно, речь не об этом.
не сравнивай свой фреймворк с WPF. У меня есть один проект на WPF. там вообще нету ни одного Id или имени элемента, нету ни одной строчки императивной логики в коде. Правильный код на WPF настолько сильно отличается от твоего, что на твой даже смотреть тошно.
0K>И задался таким вопросом: а какая абстракция нужна для разработки Web приложений. Определим шкалу от "0" до "100":
0K>- на "0" будет полнейшая смесь html кода -- грубо говоря, склеиваем HTML из отдельных констант и вставляем динамическое содержимое. 0K>- на отметке "100" будет некий свой язык разметки (типа XAML) с серверными событиями, эмуляцией логики JavaScript с помощью серверного кода (все это дело компилируется (или генерирует в процессе работы) в HTML и JavaScript). Словом -- никакой связи с HTML.
0K>Ежу понятно, что истина где-то по середине, обе крайности для практического использования не пригодны. Как вы считаете, до какой степени нужно абстрагировать процесс Web-разработки? Что вы видите в идеале?
Ты не то и не от того отделяешь. Гораздо важнее отделение логики от представления, а не представления от логики. Барьер должен быть развернут в другую сторону.
Представление меняется чаще всего и очень хорошо было бы если бы эти изменения оставались на уровне представления.
, был весьма удивлен мнением некоторых людей, мол "отделять HTML-шаблон от программного кода не дает преимуществ". Главное когда Микрософт наваяли WPF -- отделение шаблона представления от кода -- было супер преимуществом.
ты настаиваешь на полном отсутствии логики в html
в wpf это не так. в xaml вполне себе есть логика.
Мне кажется тут все абстракции будут маленько "дырявыми", а что-то притянуто "за уши", потому что они строятся на основе простой вещи запрос-ответ и больше не чего.
Мне как разработчику хочется вообще не видеть html(недолюбливаю его) и при этом иметь возможность самому без напрягов сделать более-менее нормальный вид сайта.
Здравствуйте, out-of-the-way, Вы писали:
OOT>Мне как разработчику хочется вообще не видеть html(недолюбливаю его) и при этом иметь возможность самому без напрягов сделать более-менее нормальный вид сайта.
Так используйте готовые CMS -- в чем проблема. Все равно кому-то нада работать с HTML. Нельзя в вебе от этого уйти.
Здравствуйте, 0K, Вы писали:
0K>Да, в этом небольшое сходство есть.
Уже прогресс.
0K>Но у меня нет жесткой связи. Нет необходимости (и простой возможности) вставлять HTML-теги в код -- связь только по Id. У Lift мне в глаза сразу бросилась смесь HTML и кода на стороне кода. У меня такого нет.
В шаблонах у них тоже нет кода. А то что у них есть возможность использовать микро шаблоны ХМЛ-я из кода, так это как раз большое благо для программиста. Все равно будешь вынужден манипулировать (формирвоать/заменять) ХМЛ-ем из своего кода. И очень важно, чтобы это было просто и удобно. Делать это через DOM API очень и очень сложно.
Есть несколько подходов урастить манипуляцию DOM-ом. Один из них DSL формирования ХМЛ-я и паттерн-матчинг. Именно это и пспользовано в Lift-е. Только это сделано за счет того, что поддержка ХМЛ-я встроена прямо в язык. Так что на шарпе тебе это не грозит. Другой подход можно назвать XSLT-шным. Когда производится трасформация ХМЛ-я на основе отдельных правил трансформации (близких к декларативным).
0K>P.S. 0K>Для оживления атмосферы люблю прибегнуть к "красному словцу".
Если бы ты для оживления дела еще анализировал что тебе говорят и не отбрасывал бы сказанное только на основании того, что не понял или не привык, то конструктива было бы больше.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, out-of-the-way, Вы писали:
OOT>>Мне как разработчику хочется вообще не видеть html(недолюбливаю его) и при этом иметь возможность самому без напрягов сделать более-менее нормальный вид сайта.
0K>Так используйте готовые CMS -- в чем проблема. Все равно кому-то нада работать с HTML. Нельзя в вебе от этого уйти.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, 0K, Вы писали:
0K>>Да, в этом небольшое сходство есть.
VD>Уже прогресс.
0K>>Но у меня нет жесткой связи. Нет необходимости (и простой возможности) вставлять HTML-теги в код -- связь только по Id. У Lift мне в глаза сразу бросилась смесь HTML и кода на стороне кода. У меня такого нет.
VD>В шаблонах у них тоже нет кода. А то что у них есть возможность использовать микро шаблоны ХМЛ-я из кода, так это как раз большое благо для программиста. Все равно будешь вынужден манипулировать (формирвоать/заменять) ХМЛ-ем из своего кода. И очень важно, чтобы это было просто и удобно. Делать это через DOM API очень и очень сложно.
VD>Есть несколько подходов урастить манипуляцию DOM-ом. Один из них DSL формирования ХМЛ-я и паттерн-матчинг. Именно это и пспользовано в Lift-е. Только это сделано за счет того, что поддержка ХМЛ-я встроена прямо в язык. Так что на шарпе тебе это не грозит. Другой подход можно назвать XSLT-шным. Когда производится трасформация ХМЛ-я на основе отдельных правил трансформации (близких к декларативным).
думаю вполне можно на шарпе повторить более-менее, и поддержка XML-литералов в языке какой-либо роли тут не играет.
А вот повторить более свежие CSS Selector Transforms будет чуть сложнее. Это по-моему ближе к тому, что 0K описывает.
А по сути подход Lift и есть фактически XSLT-шный ибо сниппеты (фича близкая к контроллерам в традиционном подходе) по сути есть функция NodeSeq => NodeSeq (xml -> xml в терминах скалы).
