В 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 круче!" кто-нибудь может помочь в выборе и понимании?