Здравствуйте, 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-разработке, но если связующим звеном выступает только модель данных (определённая для обоих направлений, естественно), то серверная часть никак не будет влиять на отображение этих данных и наоборот.
Это неправда. В сферических приложениях в вакууме это работает, в реальных — нет. Бессмысленно изобретать "модель данных", которая не заточена под конкретное отображение.
Если у тебя отображение постраничное, то ты и модель данных сделаешь постраничной. В противном случае ты об этом даже не задумаешься, а сделаешь абстрактный источник данных, который отдает их целиком.