Я хотел немного рассказать о проекте, который пришел мне в голову, надеюсь на помощь в его реализации.

В настоящее время ASP.NET контролы очень тяжелые и неповоротливые. Будучи очень универсальными они выполняют много лишней работы, хранят очень много лишних данных в ViewState, из которых я, например, использую максимум 10%.
Также скудно обстоят дела с JavaScript. Очень много работы производится на сервере, минимум на клиенте. Серверные контролы слабо поддаются управлению на клиентской стороне. Падает интерактивность сайта.

Идея состоит в том, чтобы разработать библиотеку базовых классов для разработки легких, быстрых и интерактивных компонентов. Суть в том, чтобы:
1. Обойти использование ViewState, а использовать другой, более производительный метод.
2. Создать возможность легкой разработки объектного представления серверного контрола на клиентской стороне и реализовать все возможности для простого взаимодействия контролов на клиенте, который будет не сильно уступать серверному.
3. На основе пункта 2 реализовать AJAX-библиотеку, суть работы которой будет состоять не в обмене HTML-кодов и переправкой огромных ViewState с клиента на сервер, а в отсылке клиентским реализациям контролов только данных! Чтобы они на их основе обновляли свое представление.

Идея еще сырая, надо думать. Кто хотел бы присоединиться?

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

M>Я хотел немного рассказать о проекте, который пришел мне в голову, надеюсь на помощь в его реализации.

M>В настоящее время ASP.NET контролы очень тяжелые и неповоротливые. Будучи очень универсальными они выполняют много лишней работы, хранят очень много лишних данных в ViewState, из которых я, например, использую максимум 10%.

Это в силу того что стараются сделать универсальные контролы, которые бы по требованиям функционала подходили бы большинству потенциальных покупателей.

M>Также скудно обстоят дела с JavaScript. Очень много работы производится на сервере, минимум на клиенте. Серверные контролы слабо поддаются управлению на клиентской стороне. Падает интерактивность сайта.

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

M>Идея состоит в том, чтобы разработать библиотеку базовых классов для разработки легких, быстрых и интерактивных компонентов. Суть в том, чтобы:
M>1. Обойти использование ViewState, а использовать другой, более производительный метод.

ViewState вещь хорошая, если рационально ее использовать, а не сгружать туда все данные с сервера.

M>2. Создать возможность легкой разработки объектного представления серверного контрола на клиентской стороне и реализовать все возможности для простого взаимодействия контролов на клиенте, который будет не сильно уступать серверному.

Все тянуть на клиента тож нехорошо, нужен баланс между сервером и клиентом, а у вас перекос получается в сторону клиента.

M>3. На основе пункта 2 реализовать AJAX-библиотеку, суть работы которой будет состоять не в обмене HTML-кодов и переправкой огромных ViewState с клиента на сервер, а в отсылке клиентским реализациям контролов только данных! Чтобы они на их основе обновляли свое представление.

А состояние контролов, где будет?

Состояние контролов хочется автоматизировать например в HiddenField'ы. И использовать их в двух вариантах: В открытом виде — по умолчанию, либо в зашифрованном(для особо важных). Такая методика позволит на стороне клиента изменять открытые параметры контрола!

А ViewState — Довольно медленная вещь. Сериализация + Base64 совсем не быстрые алгоритмы.

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

M>А ViewState — Довольно медленная вещь. Сериализация + Base64 совсем не быстрые алгоритмы.

Думаю что это экономия на спичках, тем более что ViewState можно отключать где он реально не нужен. А с хидден филдами может даже хуже получится, так как для каждого нужен ClientID и он может быть достаточно длинным, а если таких полей несколько десятков — считайте сами

Здесь я говорю не просто о переходе с одного вида на другой.

Во-первых скрытые поля откроют пути взаимодействия с JavaScript, что невозможно с ViewState.

Во-вторых, можно дать возможность частично сохранять данные. Например когда я кладу и настраиваю GridView — у меня около 40 полей в ASPX присваиваются. Зачем их хранить в ViewState если они итак присваиваются? Мне бы пригодилась возможность ЧАСТИЧНОГО отключения хранения подобных данных. например, отключение хранения оформления. Порой огромные ViewState'ы получаются от сложных страниц и страницы приходится перепроектировать...

Также в связке с JS в GridView можно было бы переходить к режиму редактирования без запросов на сервер.

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

M>Здесь я говорю не просто о переходе с одного вида на другой.

M>Во-первых скрытые поля откроют пути взаимодействия с JavaScript, что невозможно с ViewState.

M>Во-вторых, можно дать возможность частично сохранять данные. Например когда я кладу и настраиваю GridView — у меня около 40 полей в ASPX присваиваются. Зачем их хранить в ViewState если они итак присваиваются? Мне бы пригодилась возможность ЧАСТИЧНОГО отключения хранения подобных данных. например, отключение хранения оформления. Порой огромные ViewState'ы получаются от сложных страниц и страницы приходится перепроектировать...

Не совсем понял что значит присваиваются, а при постбеке тоже присваиваются?
При постбеке нужно как то ресторится, и как быть с хидден полями при постбеке? У них будет ViewState?

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

M>Также в связке с JS в GridView можно было бы переходить к режиму редактирования без запросов на сервер.

Мож оно и так, но JS писать еще тот

Здравствуйте, Аноним, Вы писали:

А>Не совсем понял что значит присваиваются, а при постбеке тоже присваиваются?
А>При постбеке нужно как то ресторится, и как быть с хидден полями при постбеке? У них будет ViewState?

Когда мы пишем

<asp:XXX Color="Blue" runat="server"/>

То присваивание значения Blue компоненту XXX будет на стадии Init независимо от постбеков.

Здравствуйте, Аноним, Вы писали:

А>При постбеке нужно как то ресторится, и как быть с хидден полями при постбеке? У них будет ViewState?

Зачем им ViewState, у них есть собственное значение (value) на основе которых можно ресторить контрол.

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

M>Здравствуйте, Аноним, Вы писали:

А>>При постбеке нужно как то ресторится, и как быть с хидден полями при постбеке? У них будет ViewState?

M>Зачем им ViewState, у них есть собственное значение (value) на основе которых можно ресторить контрол.

Ну напиши хотя бы один контрол на хидден филдах, тогда можно будет более предметно оценить достоинства и недостатки твоего подхода.

Здравствуйте, Аноним, Вы писали:

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

M>>Здравствуйте, Аноним, Вы писали:

А>>>При постбеке нужно как то ресторится, и как быть с хидден полями при постбеке? У них будет ViewState?

M>>Зачем им ViewState, у них есть собственное значение (value) на основе которых можно ресторить контрол.

А>Ну напиши хотя бы один контрол на хидден филдах, тогда можно будет более предметно оценить достоинства и недостатки твоего подхода.

Если наберется команда энтузиастов — можно будет спроектировать все и написать. Достоинства очевидны. Правильное использование JS — вот что не хватает ASP.NET, но этим пользуются PHP программисты.

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

M>Если наберется команда энтузиастов — можно будет спроектировать все и написать. Достоинства очевидны. Правильное использование JS — вот что не хватает ASP.NET, но этим пользуются PHP программисты.

Раньше этим пользовались и просто ASP 3.0 программисты

Здравствуйте, Аноним, Вы писали:

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

M>>Если наберется команда энтузиастов — можно будет спроектировать все и написать. Достоинства очевидны. Правильное использование JS — вот что не хватает ASP.NET, но этим пользуются PHP программисты.

А>Раньше этим пользовались и просто ASP 3.0 программисты

Согласен =)

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

M>Состояние контролов хочется автоматизировать например в HiddenField'ы. И использовать их в двух вариантах: В открытом виде — по умолчанию, либо в зашифрованном(для особо важных). Такая методика позволит на стороне клиента изменять открытые параметры контрола!
Надеюсь, ты в курсе, что ViewState ездит в HiddenField, и работает и в открытом, и в зашифрованном виде? И что это гораздо компактнее, чем если ты сделаешь по филду на контрол?

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

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

M>>Состояние контролов хочется автоматизировать например в HiddenField'ы. И использовать их в двух вариантах: В открытом виде — по умолчанию, либо в зашифрованном(для особо важных). Такая методика позволит на стороне клиента изменять открытые параметры контрола!
S>Надеюсь, ты в курсе, что ViewState ездит в HiddenField, и работает и в открытом, и в зашифрованном виде? И что это гораздо компактнее, чем если ты сделаешь по филду на контрол?

Здесь также речь идет о том, чтобы контрола можно было бы попросить отключить хранение ЧАСТИ данных. Например, в 95% случаев оформление хранить не надо. Также если ViewState недоступен из JavaScript, а разбитие его на несколько полей и хранение части в открытом виде позволит полноценно взаимодействовать на стороне клиента.

Здравствуйте, mdevils, Вы писали:
M>Здесь также речь идет о том, чтобы контрола можно было бы попросить отключить хранение ЧАСТИ данных. Например, в 95% случаев оформление хранить не надо.
Не очень понятно, почему именно его хранить не надо.
Надеюсь, ты в курсе, что ViewState не хранит статическую разметку, и вообще всю ту разметку, которую удалось выполнить в Page_Init?

M>Также если ViewState недоступен из JavaScript, а разбитие его на несколько полей и хранение части в открытом виде позволит полноценно взаимодействовать на стороне клиента.
Не вполне понятно, зачем взаимодейстовать с ViewState на стороне клиента. Как правило, то, с чем взаимодействуют на стороне клиента, во вьюстейт не входит.
К примеру, у TextBox текст ездит не через viewstate, а через Text, т.е. атрибут Value.

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

S>Здравствуйте, mdevils, Вы писали:
M>>Здесь также речь идет о том, чтобы контрола можно было бы попросить отключить хранение ЧАСТИ данных. Например, в 95% случаев оформление хранить не надо.
S>Не очень понятно, почему именно его хранить не надо.
S>Надеюсь, ты в курсе, что ViewState не хранит статическую разметку, и вообще всю ту разметку, которую удалось выполнить в Page_Init?

Уверены?)) Проверяли?) Я проверял =)

M>>Также если ViewState недоступен из JavaScript, а разбитие его на несколько полей и хранение части в открытом виде позволит полноценно взаимодействовать на стороне клиента.
S>Не вполне понятно, зачем взаимодейстовать с ViewState на стороне клиента. Как правило, то, с чем взаимодействуют на стороне клиента, во вьюстейт не входит.
S>К примеру, у TextBox текст ездит не через viewstate, а через Text, т.е. атрибут Value.

TextBox достаточно простой. Существуют сложные комноненты. Там так данные не задаж, а интерактивность на стороне клиента важна..

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

M>Здесь я говорю не просто о переходе с одного вида на другой.

M>Во-первых скрытые поля откроют пути взаимодействия с JavaScript, что невозможно с ViewState.

M>Во-вторых, можно дать возможность частично сохранять данные. Например когда я кладу и настраиваю GridView — у меня около 40 полей в ASPX присваиваются. Зачем их хранить в ViewState если они итак присваиваются? Мне бы пригодилась возможность ЧАСТИЧНОГО отключения хранения подобных данных. например, отключение хранения оформления. Порой огромные ViewState'ы получаются от сложных страниц и страницы приходится перепроектировать...

Отключи ViewState для GridView и дергай данные из базы (объекта, XML) при каждой загрузке.
Уж очень большой ViewState можно хранить на сервере.

Есть уже такие контролы, которые работают "по своему".
Вот например: http://www.componentart.com

M>1. Обойти использование ViewState, а использовать другой, более производительный метод.

1. Используют свой CA State.

M>2. Создать возможность легкой разработки объектного представления серверного контрола на клиентской стороне и реализовать все возможности для простого взаимодействия контролов на клиенте, который будет не сильно уступать серверному.

2. Все свойства доступны как на сервере, так и на клиенте.

M>3. На основе пункта 2 реализовать AJAX-библиотеку, суть работы которой будет состоять не в обмене HTML-кодов и переправкой огромных ViewState с клиента на сервер, а в отсылке клиентским реализациям контролов только данных! Чтобы они на их основе обновляли свое представление.

3. Могут подгружать только данные, как со страниц, так и из веб сервисов.

Одна проблема — они далеко не легкие, при детальном рассмотрении жрут кучу памяти, в том числе и с leak'ами. На тяжелых приложениях это становится реально заметно. Так что проблема универсальность vs. скорость остается и в описанном сценарии, ИМХО.