В Web я новичок (три дня стажа, до этого только мобильные приложения) и чего-то не понимаю, но текущее положение дел с графическими компонентами в Web'е мне кажется очень странным.
Для меня казалось (и пока кажется) естественным описать все компоненты сразу в html и css (ну или xml + xslt + css) с минимальным количеством сторонних директив для указания, откуда берутся данные. При этом:
1)почти полностью абстрагируемся от выполняемого на сервере кода (разве что завязаны на язык шаблонизаторов, например, Velocity) и технологию обработки запросов можно довольно легко сменить
2)при изменении компонента не нужно ничего перекомпилировать

Но при этом я вижу GWT-Ext, Wicket и т.д., где графические компоненты задаются жёстко в коде. Чем интересен этот подход? Отсутствуют вышеприведённые плюсы. Захотел сменить движок View или перейти с Java на .NET — переписывай UI. Почему они тогда так популярны?

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

D>Но при этом я вижу GWT-Ext, Wicket и т.д., где графические компоненты задаются жёстко в коде. Чем интересен этот подход? Отсутствуют вышеприведённые плюсы. Захотел сменить движок View или перейти с Java на .NET — переписывай UI. Почему они тогда так популярны?
Забыл упомянуть про плюсы. Я пока вижу только один — возможность нормального наследования компонентов.

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

D>Захотел сменить движок View или перейти с Java на .NET — переписывай UI.

в ASP.NET афаик UI берется из xml..

D>Но при этом я вижу GWT-Ext, Wicket и т.д., где графические компоненты задаются жёстко в коде. Чем интересен этот подход? Отсутствуют вышеприведённые плюсы. Захотел сменить движок View или перейти с Java на .NET — переписывай UI. Почему они тогда так популярны?

ИМХО после последних нововведений Microsoft (начиная с framework 2.0) они уже намного менее популярны.

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

D>>Захотел сменить движок View или перейти с Java на .NET — переписывай UI.

F>в ASP.NET афаик UI берется из xml..

откуда-откуда?

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

D>Здравствуйте, Donz, Вы писали:
D>Забыл упомянуть про плюсы. Я пока вижу только один — возможность нормального наследования компонентов.

Компонентный подход хорош не только наследованием, но и композицией компонент. Как вы будете в разметке хранить контрол типа GridView из ASP.NET?

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

F>Здравствуйте, Donz, Вы писали:
D>>Захотел сменить движок View или перейти с Java на .NET — переписывай UI.
F>в ASP.NET афаик UI берется из xml..

Неправда.
в ASP.NET разметка берется из aspx файла, в котором находится html код с вкраплениями разметки для серверных контролов.

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

G>Компонентный подход хорош не только наследованием, но и композицией компонент. Как вы будете в разметке хранить контрол типа GridView из ASP.NET?
Насчёт ASP.NET понятия не имею, я его в глаза не видел
Что касается композиции, то я в первом посте упомянул шаблонизатор, который имеет свой простенький язык, позволяющий вставлять другие файлы (компоненты в html коде) с передачей параметров. То есть, проблем с этим нет.

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

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

G>>Компонентный подход хорош не только наследованием, но и композицией компонент. Как вы будете в разметке хранить контрол типа GridView из ASP.NET?
D>Насчёт ASP.NET понятия не имею, я его в глаза не видел
Попытаюсь объяснить. Серверные контролы — фактически классы, определяющие результирующую разметку — позволяют задать не только внешний вид, но и поведение контрола. Например GridView сам (без постороннего кода) позволяет переключаться в режим редактирования и изменять данные из источника.

D>Что касается композиции, то я в первом посте упомянул шаблонизатор, который имеет свой простенький язык, позволяющий вставлять другие файлы (компоненты в html коде) с передачей параметров. То есть, проблем с этим нет.
Разметка html не определяет поведение контрола, см пример про GridView выше.

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

D>>Что касается композиции, то я в первом посте упомянул шаблонизатор, который имеет свой простенький язык, позволяющий вставлять другие файлы (компоненты в html коде) с передачей параметров. То есть, проблем с этим нет.
G>Разметка html не определяет поведение контрола, см пример про GridView выше.
Яваскрипт никто не отменял. Не знаю, как в ASP.NET, но тот же GWT-Ext или Java Server Faces в конечном счёте клиенту отдают самогенерённый html + js. Или же программист сам определит этот контрол в html + js и практически отвяжется от конкретной технологии на серверной стороне.

G>Попытаюсь объяснить. Серверные контролы — фактически классы, определяющие результирующую разметку — позволяют задать не только внешний вид, но и поведение контрола. Например GridView сам (без постороннего кода) позволяет переключаться в режим редактирования и изменять данные из источника.

Серверный код в ASP.NET, касающийся создания контрола и выставления его базовых свойств генерируется автоматически. Итого есть:

1) .aspx — задает отображение. Рассмотрим на более простом примере — кнопке. В aspx файле будет запись

<asp:Button ID="Button1" runat="server" Text="Button" />

в том месте, где будет размещаться кнопка. Параметры отображения это ширина и высота кнопки, их можно добавить

<asp:Button ID="Button1" runat="server" Text="Button" Height="20px" Width="100px" />

Параметр runat="server" означает, что это серверный контрол.

2) .vb (или .cs или ...) — код. Здесь можно подписываться на различные events

Protected Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button1.Click
...
End Sub

Если хочется сделать параметры отображения "на лету", то надо подписаться на событие формы, например Page.Init или Page.Load и там писать Button1.CssClass = "myClass".

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

D>Яваскрипт никто не отменял. Не знаю, как в ASP.NET, но тот же GWT-Ext или Java Server Faces в конечном счёте клиенту отдают самогенерённый html + js. Или же программист сам определит этот контрол в html + js и практически отвяжется от конкретной технологии на серверной стороне.
Еще раз повторяю пример про GridView. Он позволяет изменять данные (в БД например) без дополнительного кода. С помощью разметки и Javascript такое сделать не получится (без обходных каналов, типа веб-сервиса)

G>Еще раз повторяю пример про GridView. Он позволяет изменять данные (в БД например) без дополнительного кода. С помощью разметки и Javascript такое сделать не получится (без обходных каналов, типа веб-сервиса)

В ASP.NET 3.5 получится, более того — ни строчки кода. Более того, грид можно сделать с paging'ом и сортировкой и без обновления всей страницы когда сортируешь, только гридовая часть. Вот такие чудеса...

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

G>Еще раз повторяю пример про GridView. Он позволяет изменять данные (в БД например) без дополнительного кода. С помощью разметки и Javascript такое сделать не получится (без обходных каналов, типа веб-сервиса)
От веб-сервисов и т.д. я и не отказываюсь (в моём случае на стороне сервера выполняется сервлет), но тема не об этом, а об абстрагировании представления от бизнес-логики, что мне на данный момент кажется маловозможным в фреймворках типа GWT-Ext, Wicket или подобных вещах, где графический интерфейс жёстко завязан на используемом языке, платформе, библиотеке.
Можешь сказать, что выполняется на стороне клиента в твоём примере про GridView? Неужели надо ставить .NET для подобных сайтов? Назад к Java Applets?

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

D>От веб-сервисов и т.д. я и не отказываюсь (в моём случае на стороне сервера выполняется сервлет), но тема не об этом, а об абстрагировании представления от бизнес-логики, что мне на данный момент кажется маловозможным в фреймворках типа GWT-Ext, Wicket или подобных вещах, где графический интерфейс жёстко завязан на используемом языке, платформе, библиотеке.
Это как раз основной недостаток веб-форм.

D>Можешь сказать, что выполняется на стороне клиента в твоём примере про GridView?
Только отправка формы.

D>Неужели надо ставить .NET для подобных сайтов? Назад к Java Applets?
Нет, на клиенте нужен только браузер.

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

D>>От веб-сервисов и т.д. я и не отказываюсь (в моём случае на стороне сервера выполняется сервлет), но тема не об этом, а об абстрагировании представления от бизнес-логики, что мне на данный момент кажется маловозможным в фреймворках типа GWT-Ext, Wicket или подобных вещах, где графический интерфейс жёстко завязан на используемом языке, платформе, библиотеке.
G>Это как раз основной недостаток веб-форм.
Ну да, о чём и спич

D>>Можешь сказать, что выполняется на стороне клиента в твоём примере про GridView?
G>Только отправка формы.
Имеется в виду технология на стороне клиента. Подозреваю, что JS, так?

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

G>Еще раз повторяю пример про GridView. Он позволяет изменять данные (в БД например) без дополнительного кода.

На стороне клиента это всё равно только HTML и JavaScript.

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

A>Здравствуйте, gandjustas, Вы писали:
G>>Еще раз повторяю пример про GridView. Он позволяет изменять данные (в БД например) без дополнительного кода.
A>На стороне клиента это всё равно только HTML и JavaScript.
Конечно, но каким-либо шаблоном (в html например) его не опишешь.

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

G>>>Еще раз повторяю пример про GridView. Он позволяет изменять данные (в БД например) без дополнительного кода.
A>>На стороне клиента это всё равно только HTML и JavaScript.
G>Конечно, но каким-либо шаблоном (в html например) его не опишешь.

Современные браузеры позволяют написать что-то вроде:

<div class="grid-view"></div>

А всё остальное вынести в отдельные JavaScript- и CSS-файлы. И это будет работать.

Так по сути без акцента на конкретной технологии и флейма "а .NET круче!" кто-нибудь может помочь в выборе и понимании?

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

A>Современные браузеры позволяют написать что-то вроде:
A>

<div class="grid-view"></div>

A>А всё остальное вынести в отдельные JavaScript- и CSS-файлы. И это будет работать.
Да ну. А как JS будет выполнять загрузку данных в грид или их изменение?
Может вам не гадать, а попробовать написать чтонить на ASP.NET?
Знаний языка не требуется.

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

D>Но при этом я вижу GWT-Ext, Wicket и т.д., где графические компоненты задаются жёстко в коде. Чем интересен этот подход? Отсутствуют вышеприведённые плюсы. Захотел сменить движок View или перейти с Java на .NET — переписывай UI. Почему они тогда так популярны?

Потому что во многих областях очень редко когда нужно перейти с Java на .NET или даже принципиально поменять движок (при том, что UI не меняется).

Такая схема "более проста". А точнее — у нее меньший порог вхождения (по сравнению с моделью жесткого разделения view/controller), соответственно проще найти людей для того, чтобы "фигачить формы". При этом она вполне работоспособна. Вот и прижилась такая технология.

Однако есть MVC фреймворки, и они вполне популярны — даже MS уже созрела выпустить свой MVC фреймворк под .NET.

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

D>Так по сути без акцента на конкретной технологии и флейма "а .NET круче!" кто-нибудь может помочь в выборе и понимании?
Для Java и .NET существуют фреймворки, позволяющие использовать контролы с инкапсулированной функциональностью. Недостаток таких фреймворков — более тесная свзяь между бизнес-логикой и представлением.
Также есть фреймворки реализующие более сильное отделение логики от представления, что также дает возможность независимо менять шаблон отображения (например HTML код). Но реализация тогоже грида с возможностью редактирования данных — задача более сложная.

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

A>>Современные браузеры позволяют написать что-то вроде:
A>>

<div class="grid-view"></div>

A>>А всё остальное вынести в отдельные JavaScript- и CSS-файлы. И это будет работать.
G>Да ну. А как JS будет выполнять загрузку данных в грид или их изменение?

Аналогично тому, как он делает это в ASP.NET.

G>Может вам не гадать, а попробовать написать чтонить на ASP.NET?

Я не гадаю, я знаю.

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

G>>Да ну. А как JS будет выполнять загрузку данных в грид или их изменение?
A>Аналогично тому, как он делает это в ASP.NET.
В ASP.NET это делает сервеный код, скомплированный с сборки. Объясните как это будет делать Javascript

G>>Может вам не гадать, а попробовать написать чтонить на ASP.NET?
A>Я не гадаю, я знаю.
ASP.NET вы не знаете.

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

G>>>Да ну. А как JS будет выполнять загрузку данных в грид или их изменение?
A>>Аналогично тому, как он делает это в ASP.NET.
G>В ASP.NET это делает сервеный код, скомплированный с сборки. Объясните как это будет делать Javascript

Взаимодействовать с серверным кодом, написанным на чём угодно, аналогично тому как клиентский код ASP.NET-контрола взаимодействует с серверным кодом.

G>>>Может вам не гадать, а попробовать написать чтонить на ASP.NET?
A>>Я не гадаю, я знаю.
G>ASP.NET вы не знаете.

Я этого и не утверждал.

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

A>Взаимодействовать с серверным кодом, написанным на чём угодно, аналогично тому как клиентский код ASP.NET-контрола взаимодействует с серверным кодом.
А теперь самое главное. Клиентский код грида НИКАК не взаимодействует с серверным кодом.

G>>>>Может вам не гадать, а попробовать написать чтонить на ASP.NET?
A>>>Я не гадаю, я знаю.
G>>ASP.NET вы не знаете.
A>Я этого и не утверждал.
Тогда в чем заключается знание?

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

A>>Взаимодействовать с серверным кодом, написанным на чём угодно, аналогично тому как клиентский код ASP.NET-контрола взаимодействует с серверным кодом.
G>А теперь самое главное. Клиентский код грида НИКАК не взаимодействует с серверным кодом.

Да? И откуда же берутся данные? Впрочем, это не важно, их можно тупо забить в отдаваемый клиенту код. Но вот как изменённые данные попадают обратно на сервер, очень интересно узнать.

G>>>ASP.NET вы не знаете.
A>>Я этого и не утверждал.
G>Тогда в чем заключается знание?

Знание о загрузке данных на клиент, изменении их и отправке обратно на сервер. Безотносительно технологии.

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

A>Да? И откуда же берутся данные? Впрочем, это не важно, их можно тупо забить в отдаваемый клиенту код. Но вот как изменённые данные попадают обратно на сервер, очень интересно узнать.
Вот и изучайте ASP.NET, много нового для себя узнаете. Не даром говорят что программист должен быть знаком с различнымми языками и технологиями.

A>Знание о загрузке данных на клиент, изменении их и отправке обратно на сервер. Безотносительно технологии.
То есть утверждаете что знание есть...
A>Но вот как изменённые данные попадают обратно на сервер, очень интересно узнать.
...а получается нет

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

A>>Да? И откуда же берутся данные? Впрочем, это не важно, их можно тупо забить в отдаваемый клиенту код. Но вот как изменённые данные попадают обратно на сервер, очень интересно узнать.
G>Вот и изучайте ASP.NET, много нового для себя узнаете.

Это что такой способ скрыть своё незнание?

G>Не даром говорят что программист должен быть знаком с различнымми языками и технологиями.

Люди много чего болтают.

A>>Знание о загрузке данных на клиент, изменении их и отправке обратно на сервер. Безотносительно технологии.
G>То есть утверждаете что знание есть...
A>>Но вот как изменённые данные попадают обратно на сервер, очень интересно узнать.
G>...а получается нет

Я хочу узнать Вашу версию, потому и спрашиваю.

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

A>Это что такой способ скрыть своё незнание?
Данные передаются банальной отправкой формы. И сам контрол этот запрос обрабатывает.

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

A>>Это что такой способ скрыть своё незнание?
G>Данные передаются банальной отправкой формы. И сам контрол этот запрос обрабатывает.

Фу! (: Так не интересно, не расчитывал, что настолько примитивная реализация, никакой интерактивности.

Придётся в моём варианте контрола добавить код создания формы и сериализации данных, впрочем отправку формы можно сэмулировать и через XmlHttpRequest.

Спасибо за объяснение.

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

G>в ASP.NET разметка берется из aspx файла, в котором находится html код с вкраплениями разметки для серверных контролов.

точно, попутался.. больше с xml работаю..

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

A>Придётся в моём варианте контрола добавить код создания формы и сериализации данных, впрочем отправку формы можно сэмулировать и через XmlHttpRequest.
Не беспокойтесь, это уже за вас сделано.

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

A>Взаимодействовать с серверным кодом, написанным на чём угодно, аналогично тому как клиентский код ASP.NET-контрола взаимодействует с серверным кодом.
Дело в том, что серверный код, "написанный на чем угодно", будет обязан выполнять определенные договоренности. JS, отрендеренный на клиенте, будет рассчитывать найти определенные данные по определенному запросу, причем в жестко определенном формате.
Вот ASP.NET (точнее, его контролы) и обеспечивает взаимное выполнение обязательств клиентской и серверной стороны. Причем для программиста это более-менее прозрачно: типа вот ты описал "тут будет грид", тут же рядом описал откуда он будет брать данные — и всё. Я имею в виду, что ты описал источник данных в серверных терминах, например SQL запрос (который JS клиенту просто недоступен вообще никак), а контрол взял на себя выполнение этого запроса на сервере и отдачу результатов клиенту в виде, например, JSON, или XML, или готового HTML.

Теоретически возможно придумать 1 (один) стандарт взаимодействия клиентских страничек и серверной стороны.
На практике это лишено смысла — чтобы возможность замены серверной части была реальной, нужно как минимум 2 реализации этого стандарта. В этом никто не заинтересован, стало быть это будет всего лишь еще один фреймворк для веба (а их уже и так десятки). Хотение перейти с Джава на Нет бывает в природе очень редко.

Кроме того, стандарт будет связывать руки разработчикам — наши представления о том, как именно должны взаимодействовать странички в браузере с кодом на сервере, очень сильно изменились за последние 10 лет.

Впрочем, в последнее время стала проявляться тенденция делать Pure JS-контролы. Они не накладывают никаких требований на серверную платформу, а всего лишь просят отдать им данные в некотором определенном виде. Вот, например мой любимый: http://simile.mit.edu/timeline/

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

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

A>>Взаимодействовать с серверным кодом, написанным на чём угодно, аналогично тому как клиентский код ASP.NET-контрола взаимодействует с серверным кодом.
S>Дело в том, что серверный код, "написанный на чем угодно", будет обязан выполнять определенные договоренности.

Так код ASP.NET тоже соответствует определённым договорённостям, так что нет никакой разницы в этом смысле между

<asp:GridView />

и

<div class="grid-view"></div>

Напомню, что речь шла о представлении grid view в HTML неким шаблоном.

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

A>Так код ASP.NET тоже соответствует определённым договорённостям, так что нет никакой разницы в этом смысле между
A>

<asp:GridView />

A>и
A>

<div class="grid-view"></div>

A>Напомню, что речь шла о представлении grid view в HTML неким шаблоном.
Совершенно верно. Именно об этом я и говорил. Что начнем мы со специального языка разметки, где разметка отделена от реализации, а закончим тем же ASP.NET или JSP.
Ровно потому, что всё равно будут нужны некоторые договоренности, и платформа, которая легко позволяет их реализовать.

Вот к примеру в ASP.NET (2.0) основой выполнения договоренностей является тот факт, что Postback и Callback обрабатывает та же самая страница. То есть, когда грид захочет чего-то от сервера, есть некоторая уверенность в том, что сервер к этому готов. Ровно потому, что один и тот же серверный контрол занимается как формированием клиентского представления, так и обработкой последующих запросов.

Основная проблема с аяксизацией всяческих "серверных страниц" — это поддержка кросс-страничных договоренностей. Вот в ASP.NET 2.0 ввели понятие "веб ресурсов". Типа когда ты отправляешь на клиента img src="" со специально сформированной ссылкой на картинку, ты уверен, что она корректно будет возвращена совершенно независимым скриптом (путем вынимания из ресурсов сборки). В 3.5 есть MVC фреймворк, где ты можешь формировать ссылки на твой же код, расположенный за пределами текущей "странички", и по прежнему быть уверенным, что они будут корректно обработаны. Распиливание платформы на "чисто клиентскую" и "чисто серверную" части приведет скорее всего только к тому, что у разработчика не будет способа 100% убедиться, что он всё сделал правильно без тщательного протыкивания всех ссылок в каждой модели браузера.

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

S>Совершенно верно. Именно об этом я и говорил. Что начнем мы со специального языка разметки, где разметка отделена от реализации, а закончим тем же ASP.NET или JSP.
Не совсем верное сравнение. JSP, в принципе, подходит для отображения данных, если в него не пытаться запихать логику. В ASP.NET, насколько я знаю, контрол не только содержит описание графического интерфейса(то есть компонент сам генерит html + js, который отправляется клиенту), но и бизнес-логику.
S>Ровно потому, что всё равно будут нужны некоторые договоренности, и платформа, которая легко позволяет их реализовать.
Договорённость о модели данных — это одно. А вот жёстко забитая логика в контрол типа GridView — это совсем другое, так как без контрола её использовать будет нельзя.

S>Распиливание платформы на "чисто клиентскую" и "чисто серверную" части приведет скорее всего только к тому, что у разработчика не будет способа 100% убедиться, что он всё сделал правильно без тщательного протыкивания всех ссылок в каждой модели браузера.
Не могу спорить, так как практически нет опыта в Web-разработке, но если связующим звеном выступает только модель данных (определённая для обоих направлений, естественно), то серверная часть никак не будет влиять на отображение этих данных и наоборот.

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

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

S>>Совершенно верно. Именно об этом я и говорил. Что начнем мы со специального языка разметки, где разметка отделена от реализации, а закончим тем же ASP.NET или JSP.
D>Не совсем верное сравнение. JSP, в принципе, подходит для отображения данных, если в него не пытаться запихать логику. В ASP.NET, насколько я знаю, контрол не только содержит описание графического интерфейса(то есть компонент сам генерит html + js, который отправляется клиенту), но и бизнес-логику.
S>>Ровно потому, что всё равно будут нужны некоторые договоренности, и платформа, которая легко позволяет их реализовать.
D>Договорённость о модели данных — это одно. А вот жёстко забитая логика в контрол типа GridView — это совсем другое, так как без контрола её использовать будет нельзя.
Логика не привязана к данным, это логика только поведения контрола.

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

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

S>>Совершенно верно. Именно об этом я и говорил. Что начнем мы со специального языка разметки, где разметка отделена от реализации, а закончим тем же ASP.NET или JSP.
D>Не совсем верное сравнение. JSP, в принципе, подходит для отображения данных, если в него не пытаться запихать логику.
Почему это? Насколько я помню, в JSP точно так же есть серверные контролы. Я не в курсе, насколько там развита модель серверной обработки клиентских событий.
D>В ASP.NET, насколько я знаю, контрол не только содержит описание графического интерфейса(то есть компонент сам генерит html + js, который отправляется клиенту), но и бизнес-логику.
Я не очень понимаю, что такое "бизнес-логика" в твоем понимании. Но
D>Договорённость о модели данных — это одно. А вот жёстко забитая логика в контрол типа GridView — это совсем другое, так как без контрола её использовать будет нельзя.
Гм. Мне вообще непонятно, что такое "логика, жестко забитая в контрол типа GridView".

D>Не могу спорить, так как практически нет опыта в Web-разработке, но если связующим звеном выступает только модель данных (определённая для обоих направлений, естественно), то серверная часть никак не будет влиять на отображение этих данных и наоборот.
Это неправда. В сферических приложениях в вакууме это работает, в реальных — нет. Бессмысленно изобретать "модель данных", которая не заточена под конкретное отображение.
Если у тебя отображение постраничное, то ты и модель данных сделаешь постраничной. В противном случае ты об этом даже не задумаешься, а сделаешь абстрактный источник данных, который отдает их целиком.

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

D>>Не совсем верное сравнение. JSP, в принципе, подходит для отображения данных, если в него не пытаться запихать логику.
S>Почему это? Насколько я помню, в JSP точно так же есть серверные контролы. Я не в курсе, насколько там развита модель серверной обработки клиентских событий.
Если не ошибаюсь, то это появилось в Java Server Faces.

Насчёт остального пока не буду мутить воду. Попробую конкретные вещи, тогда и буду рассуждать далее.
За советы, объяснения всем спасибо.

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

D>Так по сути без акцента на конкретной технологии и флейма "а .NET круче!" кто-нибудь может помочь в выборе и понимании?

Я могу. Голый html+css не имеет штантых средств для повторного использования кода.
Это замедляет создание большого количества однотипных (с точки зрения html тегов, а не логики) страниц и последующей их модификации.

Осознанно это было ещё в дремучих апачах, где была и есть возможность ставить инклюды в html страницы.
Логичным продолжением этой идеи стали кастом таги в исполнении jsp/asp и легковестных технологий вроде velosity.
С ними html превратился в "процедурный" язык.

Стало возможным пердставлять html-страницу не как набор html тагов, а как набор компонент (header, footer, таблица с сортировкой, etc).

Следующим шагом стало осознание, что отрисовку компонент упростили, а их life-cycle так и пишется ручками.
И тогда появились технологии подобные JSF/ASP.NET и AJAX. Теперь у компонентов на странице появилось поведение: каждый компонент может жить на старнице "своей жизнью" и программисту даже думать не надо о том, как это обеспечивается (ему и так дргих дел хватает).
html стал "объекто-ориентированным"

Прикинь, в качестве упражнения, сколько времени потребуется, чтобы написать красивый выплывающий календарь для ввода даты в форме на html+js и заиспользовав готовые решения на фреймворках от sun/ms и насколько просто его будет потом использовать.

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

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

D>>Так по сути без акцента на конкретной технологии и флейма "а .NET круче!" кто-нибудь может помочь в выборе и понимании?

NGG>Я могу. Голый html+css не имеет штантых средств для повторного использования кода.
NGG>Это замедляет создание большого количества однотипных (с точки зрения html тегов, а не логики) страниц и последующей их модификации.

ExtJS видал? Чем не переиспользуемые компоненты?

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

NGG>>Я могу. Голый html+css не имеет штантых средств для повторного использования кода.
NGG>>Это замедляет создание большого количества однотипных (с точки зрения html тегов, а не логики) страниц и последующей их модификации.

WF>ExtJS видал? Чем не переиспользуемые компоненты?

Повидал , хотя называть js штатным средством я поостерёгся бы (сейчас, правда, браузеры по умнее стали и процессоры по быстрее, но ещё лет 5 назад это было не совсем так). JS библиотеки выступают альтернативой библиотекам тегов (в jsp/asp), но проигрывают (в зависимости от решаемых задач) моделям JSF/ASP.NET, где компоненты переиспользуются не только на уровне отображения данных, но и на уровне обработки (сервер сайд).
Ситуация изменилась бы, если к каждой такой js-библиотеки прилагались серверные фреймворки для различных платформ (java/net/php/whatever). ExtGWT успешно демонстрирует эту идею на практике. Но это совсем не голый html, правда?

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

F>Однако есть MVC фреймворки, и они вполне популярны — даже MS уже созрела выпустить свой MVC фреймворк под .NET.

Пока что MS созрела только выпустить Preview MVC, а, отнюдь, не все preview технологии доходят до релиза. Хотя это, конечно, шаг в сторону MVC для ASP.Net.

С Уважением, Andir!

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

A>Пока что MS созрела только выпустить Preview MVC, а, отнюдь, не все preview технологии доходят до релиза.

Эта дойдет, причем довольно скоро.