Будущее HTML

+1

PS: Давайте все же про ASP.NET vs * ибо и козе понятно что в статье гон (я не читал).

The IBM developerWorks Web site is currently under maintenance. Please try again later.

Видать добавляют интерактивности.

Будущее у хэтэмеиля большое и светлое.
то что мы видим сейчас - когда всё берётся из xml (который мастдай - по крайней мере в конфигах и как макроязык оставшись только как внутренняя _структура_ передачи данных, т.е. IPC) и прочих темплейтов на сервере - тупиковый и крайне неэффективный (по многим критериям) путь (jsp - копирование саном asp, а было-бы правильнее взять подход ИИ - см ниже).

Возможности html уже давно позволяют имплементировать и коммуникационные брокеры над http/s (через невидимые IFrames) и рендеринье практически любого поведения на клиенте через дивы и скрипт. А с канвасом вообще кажется круто.
Просто нет удобных фреймвоков скрывающих сложность javascript'a и для быстрых и функциональных сайтов нужны хорошие программисты, чего никогда нет много. Например liferay прописал достаточно хороший клиентовский код (javascript) и брокер, но (на мой взгляд) - портит всё тяжёлая жава на сервере с гигантской сложностью и десятками фреймворков, что есть - ЗЛО.
Сервер-сайт может (IMHO) и должен - только снабжать данными вышеназванный брокер по ID сессии и возвращать 1)статические файлы (имиджи, css и пре-генерированные куски html) и 2)очень простые одно-слотовые темплейты (как классические AI-фреймы).
В этом случае View (из MVC) формируется на клиенте (что эффективно), сервер занимается только данными из базы и сессиями (жаваскриптовые массивы вставляемые в вышеназванный темплейт), а клиентовый жаваскрипт является контроллером.
художники счастливы и занаты ВИЗИВИГОМ и не выбывают из проектов на начальных стадиях. Программисты не занимаются стилем.

И ещё: только не надо говорить что стратс - это хороший MVC. Я было хотел написать статью что стратс ужасен для больших проектов, а все только и повторяют одно и то-же переписывая из одной книжки в другую.
для затравки (сорри за английский и ошибки - лень переводить):
* It is agreed by everyone <...> that ActionForms (an object representation of an HTML form) is an anomaly in the MVC realm because can't be fit into both View and Controller. So, for interactive, data transfer nature of the forms there is no place in struts (in pure MVC model), and static html even better live without struts ;) Which means that MVC2 is not proper (correctly chosen) pattern for the web model.
* Struts built on and implements MVC2. But there are many partitioning patterns known, such as pipe as well as others. Struts limits developer to MVC2 only (In many sircumstances PIPE pattern is more appropriate: see filters and many others). By limiting yourself by MVC2 - you are limiting by one design pattern only - for all life situations and this is really bad.
* struts are slow (comparing with pure servlets implementations)
* ActionForm's validate() is not recommended for business logic checks and recommended <...> only for field validation. As a result - validation is done in more than one place (business logic validation not recommended in struts <...>). And in most cases field-validation and relationship validations cannot be easily distinguished from business logic validation and inseparable (example: validation depending on user type etc).
* declarative config (declarative xml configs) approach is much more buggy-prone than procedural (errors in runtime vs compile-time). The power of strongly typed java is diminished using frameworks which have logic, bindings, multi-level maps etc in xml (readability of xml is another issue);
....

> ActionForm's validate() is not recommended for business logic checks and recommended <...> only for field validation. As a result - validation is done in more than one place (business logic validation not recommended in struts <...>).

Ну и х? Ну и пускай введенный email для регистрации проверяется на допустимость в ActionForm а его действительность в SignUpAction. Чего тут? Наоборот ИМХО логично делить разные виды валидации данных.

> declarative config (declarative xml configs) approach is much more buggy-prone than procedural

ИМХО отдает маразмом... Что лучше в код зашивать URI на котором Action висит?

А нельзя ли ссылочку на работающий WinServ2003? Но только без киски! А то похоже на 3.14здёж!

Брехня!

просто когда логика и здесь, и там, а также ещё в нескольких местах - то это уже нельзя называть единым контроллером - он размазан. Если стратс не занимаются также и View а модель - тем более отдельно, то простите, где тут присутствует хотя бы _один_ польноценный компонент? (для MVC должны быть все 3) Сравните с тем же свингом, который тоже не идеален. А здесь - ради чего столько попугайских упоминания про MVC? Шибко модно просто. Но паттернов как я сказал - гораздо больше - даже для борьбы только со сложностью.
Чем копаться в тысячах кусочках, Action'ах, связывать с длиннющими конфигами (когда это действительно большой проект, писавшийся много лет разными подрядчиками, фирмами итд, конфигов много, имена плохие, никто не имеет Big picture итд) то это гораздо хуже моря сервлетов где проще запустить дебаггер + глядеть в doxygen-генерированный код или javadoc для той-же (нелюбимой мной) жавы и последовательно разбираться.
В стратс логика размазана по многим конфигам (в случае с struts/tiles/итд) - как спагетти, а сложность-то никуда не девается! Она размазана, причём проверить можно только запустив. А если цикл перекомпиляций/деплоймента - минуты + куча телодвижений?

>Что лучше в код зашивать URI на котором Action висит?

Ни в коем случае. Всё конфигурируемое - в базе, просто кидаться это должно из JSvar - слота (или JS-массивов любой размерности, хэш - ещё лучше смоделировать) жаваскриптом на месте.

Хз хз... насщет Tiles - так это просто из лепестков собранный View. Определяется в конфиге. Вроде все гладко. А в Стратс можно же на модули побить проект. Или я что-то упустил?

> писавшийся много лет разными подрядчиками, фирмами итд

Дык имхо любая софтина писаная черти кем превратиться со временем в парашу.

А как можешь asp.net прокомментировать? У меня вот к нему душа не лежит... клепаю вот щас Стратс для .NET :) И еще профанацию Taglibs так как чертовы серверные страницы ASP.NET никуда не годятся если делать что-нибудь выходящие за границы поставленные МСкой.

> Ни в коем случае. Всё конфигурируемое - в базе, просто кидаться это должно из JSvar - слота (или JS-массивов любой размерности, хэш - ещё лучше смоделировать) жаваскриптом на месте.

В стратс вроде для этого и реализованы "дайджесты" в виде плагинов. Пиши свой плагин для поднятия конфигурационной информации и держи ее хоть в XML с подсветкой хоть в LDAP :) Это все ИМХО так как эту часть кода Стратс я по диаганали смотрел.

Tiles - это же просто хэш. Который ещё раз запутывает дополнительными именами. Вот это мне и не нравится - что всё определяется в очень многих конфигах. Если у аппликации больше конфигов чем у апачи - плохо.
Сплошные индирекшены. Надо бороться со сложностью, а не добавлять её.
Я предлагаю бороться старым-добрым методом ИИ.

asp.net не знаю.

Что могу посоветовать - не копировать со стратс - думай сам. Там многое неправильно (имхо) но люди талдычат по-заученному: MVC, MVC, которого там и нет вобщем-то (опять же имхо).

>В стратс вроде для этого и реализованы "дайджесты" в виде плагинов. Пиши свой плагин для поднятия конфигурационной информации и держи ее хоть в XML с подсветкой хоть в LDAP :) Это все ИМХО так как эту часть кода Стратс я по диаганали смотрел.

Не знаю что такое стратс дайджесты, но меня настораживают:
* если что-то добавлялось позже чего не было by-initial-design - подозрительно (может быть привнесённая сложность в виде костылей)
* почему xml, а не правила в базе?
Тогда это был-бы просто типа такой rule-based engine для и от стратс не будет ничего (если грамотно подойти). Ну хочется имёна - можно создать хэш. Но мне гораздо больше нравится PIPE, а не разбросанные правила с введением кучи внутренних имён, которые кажется и не нужны вовсе (зачем такие ресурсы на engine отдавать?

Поздно уже что-то выдумывать... до января надо заканчивать с этим непрямым-портом и до пре беты доводить проект на этом фреймворке. Пока все устраивает - Action дергает Application Server, получает от него XML , пихает данные в контекст, дальше RequestProcessor применяет XSLT и Response.Write() :).

Я уже писал как MS яйца выкручивает, запрещая вызывать Httphandler из Httphandler'а (приходиться делать через задницу). Декомпилял класс который за это отвечает - гады проверяют и если это хендлер - бросают исключение. Отсюда несовместимость с Mono (там все рулез). Ну в обход этому я придумал одну приблуду и рекурсивный вызов RequestProcess'ора который вместо того чтобы делать RequestDispatcher.forward (или include... как там в жабе забыл) возвращает ActionMapping и ActionHandler (Servlet) снова вызывает RequestProcessor.ProcessAction если mapping != null :))) Блин че то увлекся.. кого волнует все это дерьмо.

под PIPE я конечно-же имею в виду pipeline - передачу контекста через код - другим обработчикам. Прямая аналогия - с графикой (графическим контекстом): service(Request,Response) <=> paint(Graphics)
Никто-же не наворачивает десять фреймворков (как это сейчас почему-то принято в вебе) в рисования графики! Хотя если подсчитать сколько всего рисуется, через сколько функций-классов графический контекст передаётся - думаю будет поболее объектов.

Кто мешает подгружать плагины через пайп? Создание новых классов, можно даже индиректить их имена (что имхо необязательно и даже вредно) - это и будут плагины.

Короче не люблю я indirections - они хабахнут назад будущей ценой поддержки, расширений, переделок, если даже и быстрее кодить вначале. Хотя в случае сегодняшних фреймвоков - и кодить тоже долго, и learning curve огромна. Короче, сервер-сайт в кризисе из-за сложности технологий и выход имхо - в уходе от asp-jsp-итд-теплейтного подхода с серверной генерацией каждого тага и возврату назад к HTML (+JavaScript+AI-frame-like-slot+логика_в_пайпе_или_базе)

> Ни одна серьёзная контора в здравом уме такого не сделает.

Это ты голливудским гигантам расскажи. А то они зарабатывают сотни миллионов долларов и не знают, что косячат... :)

Успехов :)

Что вы думаете насчет AJAX, приживется ли?

Тоесть подобие смарт-клиентов? (об этом щас во всю мягкие поют). Ну ведь провалились апплеты... а они ИМХО и были этими самыми смарт-клиентами...

Я не знал что такое AJAX (честно) но прочитав в википедии - понял - что это очень близко тому что я предложил выше как брокер :)

MS естественно распиарит как уникальное, новое, разработанное в подвалах корпорации ихними умами и небось запатентует.

>Все реальные пацаны ставят flashblock. А flash-only-сайты - это, как правило, попса. Ни одна серьёзная контора в здравом уме такого не сделает.

В Газбанке так похоже не думают :)))) http://gaba.ru/

апплеты как-бы умерли, хотя веб-старт - это те-же апплеты, только вид сбоку (signed + versioning) и может и не умерли-бы если бы сан так не загинался

На вопрос - смарт-ли - да, обязательно смарт. Иначе не победить сложность. Но слава богу html не собирается загибаться, а сегодня (в отличие от прошлого века) ту-же функциональность (не апплетную - а брокера и минимальные виджеты с интерактивностью) можно сделать и в браузере.

До мягких (если они имеют в виду это) кажется уже дошло.
До какой степени делать смарт - вот в чём золотое сечение.

Ещё о том что я имею в виду под smartness и почему это AI-frames.
Пустой JavaScript хэш а за ним html-коммент (типа ssi) в который вставляются в рантайме динамические массивы оверридя первые массивы. То-есть html (чистый View) может быть полноценным и отличающимся только данными в рантайме (массивы - Model) и дезайнеры могут использовать любые ихние тулы над своими дамми массивами-хешами которые и убирать в продакшене не надо. Это совсем не то что сейчас лепят от asp до пхп, которые в мозилле не отладишь.

smartness - в JS который оперирует только данной страничкой являясь контроллером. Все три компоненты MVC идеально разделены. Одной hidden переменной достаточно как PK сессии.

В ИИ-фреймах обычно есть кусок кода (поведение) которое приходит с массивом данных и этот кусок (в нашем случае JS существующий даже в webtv) разруливает только данные своей странички.

Тогда pipeline на серваке занимается почти исключительно флоу и чрезвычайно проста (если имеем 1000 стратс-правил и столько-же Actions итд итп - то в моём случае получим 1000 строк плоского кода - практически скрипта). ДБ-код - отделён идеально, т.е. ДБ-программеры заняты только данными пользуясь хоть каким языком для формирования массивов. Ляпота.

Статью не читал, но не согласен.

Сделали б вместо html простой текст с переходом по ссылкам и их подсветкой...

>А я в серверной видел 64 битные сервера под управлением ОС Уиндовс ХР, и это не шутка. это реальность. И не одна. ; (((

Вообще-то есть Windows 2003 64-bit А использовать Windows XP 64-bit как сервера не очень получится - там Microsoft затыков всяких навтыкал

> все реальные пацаны клепают сцайты на флеше

как меня ранее доставали сообщения "... загрузить с сайта www.macromedia.com?"

сейчас поставил и отключил - нет ни вопросов, ни флешь-рекламы

а на сайты идиотов, которые ВСЕ делают на флеше я не заглядываю :)

А ведь проще было бы поставить FlashBlock :-)

...HTML гнать... ссаными тряпками... будущее - вот оно jgr.dev.java.net

Апплеты были тяжеловаты, не было полного доступа ко всему DOM-у, был омерзительный на вид и тормозной на вкус GUI.

> MS естественно распиарит как уникальное

Поздняк метацца. Сегодня каждая домохозяйка уже уеврена, что AJAX придумали в Google.

> > Все реальные пацаны ставят flashblock. А flash-only-сайты - это, как правило, попса. Ни одна серьёзная контора в здравом уме такого не сделает.

> В Газбанке так похоже не думают :-)))) http://gaba.ru/

И что? gaba.ru - это их just for fun, официальный их сайт gazbank.ru

>html-коммент (типа ssi) в который вставляются в рантайме динамические массивы оверридя первые массивы

Так что, turbogears рулит?

> > > Все реальные пацаны ставят flashblock. А flash-only-сайты - это, как правило, попса. Ни одна серьёзная контора в здравом уме такого не сделает.

> > В Газбанке так похоже не думают :-)))) http://gaba.ru/

>И что? gaba.ru - это их just for fun, официальный их сайт gazbank.ru Ну да. я в курсе. габа.ру сам собой весьма беспонтов. Ваще делать такие сайты на флеше это изврат полнейший имхо. Этот сайт походу дела оринтирован на частного клиента, которому впадлу(или ещо что) лазить по основному сайту

>Ну и в чем проблема заплатить? Деньги-то есть...

куда и сколько нести чтобы под юниксом asp заработал? или отвечай или будешь очередным лоровским балаболом

>У меня работает WinServ2003 - все делает, что надо.

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

метку компакт/двд дисков оно уже научилось показывать в соответствии стандарту?

>Разве можно поменять?

ты - классический пример ит-наркомана подсевшего на продукцию мс.

вопрос, что ты делаешь с такой %;%:ой системой ценностей на лоре? ты мазохист? тебе нравится выставлять себя посмешищем? а обращаться к психиатру пробовал?

>А с канвасом вообще кажется круто.

Наресуй мне, умник, кросс-браузерный combo box на HTML/JavaScript.

>В Газбанке так похоже не думают :)))) http://gaba.ru/

Слшово "откат" знаешь?

>Ещё о том что я имею в виду под smartness и почему это AI-frames.

>Пустой JavaScript хэш а за ним html-коммент (типа ssi) в который

>вставляются в рантайме динамические массивы оверридя первые массивы.

Кастрировать. Чтобы такие не размножались.

>>Про отсутствие интерактивности афтар допустил дэзу. Берем Visual Web Developer и делаем все на ASP.NET.

[:]IIIIIIIIIIIII[:]

А не поделится ли моногуважаемый вебмастер AChulkovDotNet травой? Ну той, что он сейчас курит?

>>Все реальные пацаны ставят flashblock. А flash-only-сайты - это, как правило, попса. Ни одна серьёзная контора в здравом уме такого не сделает.

В принципе макромедийцы молодцы. Это похоже единственная кроссбраузерная технология, позволяющая без затыков на разницу реализации браузера или jvm, качественно рулить процессом общения с юзером. Все что нужно - чтоб браузер флаш держал. Даже жабаапплеты валятся, потому как jvm разные. С яваскриптом вообще черт ногу сломит. А тут монополия.

> [...] Даже жабаапплеты валятся, потому как jvm разные. [...]

Попрошу предоставить _такие_ аплеты в студию!

Сановская JVM нормально к любому браузеру плюгинится. А на всяких поделках бажных апплет и не должон работать.

>> предлагаю идею круче: вместо сайтов теперь будут обычные программы, а все будет слаться юзеру по протоколу x11 (даже с поддержкой openGL ;) ), тоесть в браузере заходим на какй-то сайтик - и получаем целую полноценную прогу, работающую на удоленном хосте, но рисующуюся на локальном.

>Прямая отгрузка вирусов потребителю без всяких промежуточных этапов >типа "нажмите эту кнопочку". Сервис высочайшего уровня :)

Ты че с дуба рухнул - X11 это картинка, исполняется все на сервере. Какие нафиг вирусы?