Готовимся к PHP6

Ruby

require 'benchmark'

str = "$a$b$c$d$a$b$c$d$a$b$c$d$a$b$c$d$a$b$c$d$a$b$c$d$a$b$c$d"

puts "split " + Benchmark.measure{1000000.times { str.split("$").join(":") } }.utime.to_s puts "gsub/string " + Benchmark.measure{1000000.times { str.gsub("$",":") } }.utime.to_s puts "gsub/regexp " + Benchmark.measure{1000000.times { str.gsub(/\$/,":") } }.utime.to_s

$ ruby 1.rb split 27.51 gsub/string 23.88 gsub/regexp 22.46 $ python 1.py sub : time=22.020000 replace : time=3.410000 join/split: time=6.660000

> 1. RoR мало распространен и почти не известен реальному заказчику.
> близко к истине, но ситуация меняется.

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

> 2. RoR не предоставляется хостерами даже на VIP-тарифных планах - только на выделенных серверах.
> для мелких проектов: vds и vps сейчас стоят сравнимо с shared hosting, так что смысла обсуждать это я не вижу.
для крупных проектов в любом случае придётся покупать нормальный dedicated.

Блин, ну почему никто не читает посты внимательно? Речь идет о СДАЧЕ МАЙЛСТОУНОВ, то есть, ПРОМЕЖУТОЧНЫХ ЭТАПОВ проекта. Зачастую (не всегда, опять же) заказчики требуют выгрузить результаты (особенно, если они предварительно частично или полностью оплачены) на сторонний хостинг. И зачастую (тоже не всегда) этим хостингом является шаред.
Или читать пост через дырку от задницы - это тоже традиция ЛОРа?

> 3. На чем писать, определяет заказчик.
> это рабовладелец, а не заказчик. К слову, заказчик оценивает технические риски исходя из репутации подрядчика, не так ли?

Существует техническое задание, где четко оговариваются все аспекты технологий, вплоть до сервера http и SQL (мы везде, где можем, используем Postgres). Мы можем выбрать свободно фреймверк (и. учитывая его потребности, откорректировать состав модулей сервера и версии этих серверных демонов).

> 4. Попробуй найти специалистов уровня Senior Developer или хотя бы
Middle Developer для RoR.
> их есть у меня. меряю пока в штуках, а не в десятках, но тем не менее.

Вот в том-то и дело, что штуками. Найти адекватного, опытного специалиста для любой технологии - это та еще проблема. Если вы проводили собеседования, то вы меня понимаете. Но найти профессионала по ПХП, Жабе или Си Шарп НАМНОГО проще, чем по Руби или Питону.

> 5. Попробуй найди QA-инженеров (а не дымных тестеров-студентов),
которые будут работать с RoR (писать тест-кейсы, проводить
автоматизированное тестирование).
> выращиваем своих потихоньку.

Мы тоже выращиваем. Но брать на работу стажеров и джуниоров - это риск. А инвестировать время (а следовательно, деньги) в переобучение (не такое, как на каких-нибудь курсах, а на реальном внутреннем проекте) - дорого, так как у квалифицированного девелопера зарплата немаленькая, и нужно платить ее независимо от того, делает он коммерческий проект или учится. :) Поэтому, с коммерческой точки зрения, время, потраченное на ОБУЧЕНИЕ СОВЕРШЕННО НОВОЙ ТЕХНОЛОГИИ - это простой. Со всеми вытекающими.

> Может, еще аргументы?
> Или вы принадлежите к числу тех менеджеров, которым нужно срубить бабла на сегодня, а завтра похер, кто будет мейнтейнить существующий код?

Не надо оскорблений. Я - из тех менеджеров, которые заботятся о заказчике (и одновременно о себе). Поэтому я выбираю массово распространенные, открытые и проверенные в реальном деле технологии, которые, при ПРАВИЛЬНОМ, грамотном применении обеспечивают легкость и удобство сопровождения. А в случае, если заказчик когда-нибудь решит сопровождать проект самостоятельно, то ему будет намного легче найти адекватных специалистов, как и нам при его (проекта) создании.

ага, так вот какой анонимус был оппонентом ? не ожидал...

ну да ладно, спасибо за потраченное время на написание теста, в примере на PHP вот только я бы заменил split (который тормознее даже preg_split) на explode - чтобы действительно получилось разделение строки на символы и затем сборка. Так вот с explode в вашем примере преимущество preg_split будет _значительно_ меньше и не факт, что в других языках разница не перейдет в отрицательную.

Далее, мы все таки говорили о Javascript, верно? Как изветсно в ПХП PCRE библиотека кэширует регекспы. Так вот, в Javascript это не делается и именно поэтому приходится изобретать кэширование, например через closures, вот хороший пример есть тут:
http://dhtmlkitchen.com/learn/js/perf/objects.jsp

Хватит сил опровергнуть еще одним тестом то, что в стандартном javascript без кэширования регекспов, связка join/split будет менее эффективной ?

> def r1(str):
>    for i in xrange(1000000):
>        re.sub(r'\$', ':', str)

def r1(str):
    r = re.compile(r'\$')
    for i in xrange(1000000):
        r.sub(':', str)

Вместо 14.630000 секунд на моем десктопе - 10.270000

>Хватит сил опровергнуть еще одним тестом то, что в стандартном javascript без кэширования регекспов, связка join/split будет менее эффективной ?

anonymous (*) (12.12.2007 18:51:08) - там на javascript тест.

Или он игнорит анонимусов? KRoN73, передай ему от нас пожалуйста :)

>Я - из тех менеджеров, которые заботятся о заказчике (и одновременно о себе). Поэтому я выбираю массово распространенные, открытые и проверенные в реальном деле технологии, которые, при ПРАВИЛЬНОМ, грамотном применении обеспечивают легкость и удобство сопровождения.

Короче, похапе - это глобально и надежно.

Если что-то сравнить с пальцем то выводы можно разные сделать. Ajax - это ajax и далеко не всегда он к месту. А viewstate - это viewstate и он кстати используется тем же MS Ajax.

Вы бы еще сударь предложили webservices использовать вместо tcp.

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

Дайте пожалуйста хороший пример где нужен вьюстейт?

>> anonymous (*) (12.12.2007 18:51:08) - там на javascript тест.

> Или он игнорит анонимусов? KRoN73, передай ему от нас пожалуйста :)

да, прошу прощения - пропустил тот пост, я не слежу за веткой.

ну что я могу сказать... Мои сомнения в преимуществе replace в случае рег. выражений подтвердились:

Ваш тест, Konqueror 3.5.8, код проверки с выводом результата:

var a1 = (new Date().getTime());
r1(str);

var a2 = (new Date().getTime());
r2(str);

var a3 = (new Date().getTime());
r3(str);

var a4 = (new Date().getTime());

document.write ( 'r1/r2/r3: ' + [ a2-a1,a3-a2,a4-a3].join('-') );


результат (средний):
r1/r2/r3: 1448-173-788

- что и требовалось доказать. Не будет удивительным, если в других броузерах будут другие результаты, но что опять таки говорит, что не всегда replace будет быстрее связки join/split, все таки затраты на компиляцию регекспа дают о себе знать.

> Лучший PHP6 - это Perl 6

"В сортах говна не разбираюсь" (c)

> Сейчас вот предстоит гемор по переводу быдлоподелий написанных на пыхе4 на пых5

И что? Сейчас вот мне предстоит перевод приложения на новый cpp компилятор и некоторые новые библиотеки, а тоже когда-то писали на века...

>Сейчас VPS хостинг начинается от 500р в месяц. Это не дорого.

в то время как обычный виртуальный хостинг стоит $4/мес за 2 гига + reseller +ror/python/perl

P.S. Достали обсуждать ASP.NET. Идите на винфак/rsdn

>> Лучший PHP6 - это Perl 6

>"В сортах говна не разбираюсь" (c)

В квотесы!

>Мои сомнения в преимуществе replace в случае рег. выражений подтвердились:

В firefox все-таки split/join медленее чем replace, как показано в том посте. Видимо в firefox регекспы сделаны качественно, а в Konq нет.

>> Лучший PHP6 - это Perl 6
>> "В сортах говна не разбираюсь" (c)
>> В квотесы!

+1 :oD

>Дайте пожалуйста хороший пример где нужен вьюстейт?

Уже приводили. Хранить текущий видимый таб, если используется несколько переключаемых панелей. Хранить ID текущей редактируемой записи. Хранить URL, куда надо редиректится после успешного сабмита формы. Хранить результаты дорогой операции, выполняемой при первой загрузке страницы.

> Короче, похапе - это глобально и надежно. Ну что вам ответить? Вы же тред целиком не читаете и аргументов не понимаете. Значит, скажу проще, чтобы для вас было понятно. Да мне абсолютно по...й, насколько это по чьему-либо мнению глобально. Надежной технологию делает ее правильное использование профессиональными разработчиками. А вручи такому, как вы даже самую совершенную - вы получите вместо проекта большое ничто (ругаться не буду - забанят), потому что подходите ко всему поверхностно. Главное мерило успеха или провала проекта - это его КОММЕРЧЕСКАЯ или ФИНАНСОВАЯ ЭФФЕКТИВНОСТЬ. И ТОЧКА. Технологическому совершенству нет предела, но оно служит только одной цели - получению прибыли. Для того, чтобы получать прибыль, нужно делать качественные проекты. И делать их качественно НЕЗАВИСИМО от применяемой технологии. А пока ситуация такова, что делать проекты на пыхе элементарно ВЫГОДНЕЕ и организационно УДОБНЕЕ, чем на руби или питоне. Аргументы я привел уже, и не только я - марш читать тред полностью. А все эти баталии Х vs Y мне абсолютно до 3,14%зды. Я надеюсь, я выразил свою мысль доходчиво для вашего уровня развития?

>Уже приводили.

Плохо приводили

>Хранить текущий видимый таб

При переходе по ссылке GET запросом оно потеряется - вариант не годится, только между формами. Вариант вообще приводил я, с целью узнать, нафига в таких случаях вьюстейт?

> Хранить ID текущей редактируемой записи.

Hidden поле чем хуже? И главное - оно проще чем вьюстейт. Ведь чтобы записать его во вьюстейт надо контрол, получается то же что Hidden поле.

>Хранить URL, куда надо редиректится после успешного сабмита формы.

referer? Опять же Hidden поле, разницы нет, но hidden-поле проще.

>Хранить результаты дорогой операции, выполняемой при первой загрузке страницы.

не первой загрузке, а при любом POST запросе. Такие запросы - редкость.

>ага, так вот какой анонимус был оппонентом ? не ожидал...

Хм. Кто-то из нас чего-то не понял. И никогда и нигде не пишу анонимно. Принцип такой.

>вот только я бы заменил split (который тормознее даже preg_split) на explode

Забавно. Полез было ткнуть пальцем в документацию, а оказалось, что они сейчас _не_ алиасы :) А раньше в доке прямо говорилось, что split - это алиас explode.

А проверить не сложно :) Правда, уже на другой машине. Результат:

preg_replace: time=9.83720612526
str_replace : time=5.19437503815
join/explode: time=17.3154978752

>Далее, мы все таки говорили о Javascript

Но в теме про PHP ;)

>Вместо 14.630000 секунд на моем десктопе - 10.270000

Прекомпилированный регексп в сравнении с предыдущими методами:

sub : time=18.540000
replace : time=1.170000
join/split: time=4.600000
compile : time=11.860000

>Или он игнорит анонимусов? KRoN73, передай ему от нас пожалуйста :)

Вроде, нет. Хотя я уже мало чего соображаю после четырёх часов в TeamFortress :) А сейчас мне ещё работать... на PHP... :D

>Или читать пост через дырку от задницы - это тоже традиция ЛОРа?

Самая древняя, обусловленная средним возрастом среднего ЛОРовца. Здесь серьёзных обсуждений больше нет.

А вот пример реальный, и доступный для ВАШЕГО уровня развития: MS Windows* . Может вы мне и сейчас про гениаьных разработчиков от M$ напоёте. И повторите, что мерило качества продукта её коммерческая удача? А мне до звезды мнение вот таких неодучек как вы, не в силах понять, что мерить можно только уже мёртвый продукт, так сказать 'анатомирование'. Так как пока есть заинтересованные и богатые лица, нет и объективности. Более того, что сейчас кажется жашибись технологией, завтра может оказаться фуфлом, просто за счёт того, что временный успех этой технологиий достигался не её общепринятым совершенством, а за счёт внешних вливаний, PR и тд. Это называется 'пузырь'. Так что всё ещё сложнее чем вы думаете, когда обзываете других дураками.

Читал с конца обсуждения ;-)

И ещё, я согласен, что никакая технология не может быть 'глобальной'. Зацепила безапелляционность 'объективного мерила успеха'.

И что за эпопея с perl6 расскажите? Если не в теме так молчите в тряпочку. Его(perl6) никогда не планировали к нужному сроку. Читай faq: "In regards to Perl 6, the answer on release dates is really "when it's ready". " К тому же проблем как то не видно. делают пони(perl5 под parrot), делают совместимый режим в perl6 с пятым, делают 5.10 в который уже кучку перенесли из perl6.

> Если не в теме так молчите в тряпочку.

Пошел нафиг ;) Если ты сходил о ссылке с ЛОр думаешь самый умный ? :)

> И что за эпопея с perl6 расскажите?

Сначала, задолго до того как вы прочитали этот ФАК, perl6 планировалось зарелизить как можно быстрее. По причине того что количество людей понимающих адский исходник perl5 сокращалась, и близко был момент
когда поддерживать perl5 было бы некому, вследствие его запутанности.

Но попытки пререманить народ с 5 на 6 оказались гораздо менее успешными - массу кода под новый синтаксис никто переписывать сильно не хотел.
Это затормозило развитие perl6. Потом основная идея - переделать все под попугай не встретила понимания сообщества: те у кого были виртуальные машины, типа питона, их менять не захотели. В стиле "Ну если она у вас будет убер-крутая, тогда мы подумаем". Перлисты ушли делать убер-крутую виртальную машину...

А потом, во первых, к большому удивлению начали появлятся люди нормально понимающие исходник perl5 и придумали perl5 на попугае. Оба этих события снизили накал страстей, и мигрировать старый код не нужно если даже перл 5 умрет и вроде как решили проблему, перл5 не умер.

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

Возникла ситуация как с Хурд - комбинация трудности/нерешенности задачи и того что разработчики свалили на простые решения типа Линукса и БСД.

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

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

> Блин, ну почему никто не читает посты внимательно? Речь идет о СДАЧЕ МАЙЛСТОУНОВ, то есть, ПРОМЕЖУТОЧНЫХ ЭТАПОВ проекта. Зачастую (не всегда, опять же) заказчики требуют выгрузить результаты (особенно, если они предварительно частично или полностью оплачены) на сторонний хостинг. И зачастую (тоже не всегда) этим хостингом является шаред.

у вас таки странные заказчики. у нас свои pre-production серверы, куда мы выкатываем демки. заказчик при желании может зайти на фтп и слить всё, что ему интересно. при чем тут левые хостинги?

> Существует техническое задание, где четко оговариваются все аспекты технологий, вплоть до сервера http и SQL (мы везде, где можем, используем Postgres). Мы можем выбрать свободно фреймверк (и. учитывая его потребности, откорректировать состав модулей сервера и версии этих серверных демонов).

это всё так, да. Но выбор технологии вообще не в компетенции заказчика в 99% случаев. И в SRS пишется не ультимативное решение Самого, а нечто обсуждённое.

> Вот в том-то и дело, что штуками. Найти адекватного, опытного специалиста для любой технологии - это та еще проблема. Если вы проводили собеседования, то вы меня понимаете. Но найти профессионала по ПХП, Жабе или Си Шарп НАМНОГО проще, чем по Руби или Питону.

профессионал по пхп? не смешите, право слово.

> Но брать на работу стажеров и джуниоров - это риск. А инвестировать время (а следовательно, деньги) в переобучение (не такое, как на каких-нибудь курсах, а на реальном внутреннем проекте) - дорого, так как у квалифицированного девелопера зарплата немаленькая, и нужно платить ее независимо от того, делает он коммерческий проект или учится. :) Поэтому, с коммерческой точки зрения, время, потраченное на ОБУЧЕНИЕ СОВЕРШЕННО НОВОЙ ТЕХНОЛОГИИ - это простой. Со всеми вытекающими.

брать на работу джуниоров - не такой высокий риск, ибо их много. И вообще брать на работу кого бы то ни было также чревато простоями. Или Вы находите таких монстров, которые за полчаса после собеседования разбираются в проекте на пятьдесят с мелочью тысяч строк? И сможет исправлять ошибки других авторов с такой же скоростью, как и они сами? И прочая, прочая, прочая...

> Не надо оскорблений. Я - из тех менеджеров, которые заботятся о заказчике (и одновременно о себе). Поэтому я выбираю массово распространенные, открытые и проверенные в реальном деле технологии, которые, при ПРАВИЛЬНОМ, грамотном применении обеспечивают легкость и удобство сопровождения.

читать пост через дырку от задницы - это тоже традиция ЛОРа? (c) вопрос - это ни в коей мере не оскорбление. Я уточнял верность собственного впечатления, ничего более.

И вот не надо о правильном и грамотном применении пхп, договорились? В качестве примера заставьте его хотя бы научиться сравнивать объекты. Чтобы не получалось вот так: http://www.krupenik.com/bugs/php/2007121101.phps

Ути-пути на мозольку наступили? Ты от Ларри письмецо подобное приведи или высказывание. А то тролить все могут.

> При переходе по ссылке GET запросом оно потеряется - вариант не
> годится, только между формами.
Когда вы в GUI приложении открываете новую форму, то будет ли у вас выбран тот же tab что был выбран вами неделю назад определяется вовсе не поведением GUI Framework.

Переход GET запросом - это с точки зрения приложения открытие новой формы.

> только между формами.
Не понятно о чем речь? ViewState - это для работы с _одной_ формой. Для хранения данных между формами и между GET запросами используется сессия.

Имхо viewstate который гоняется с клиента на сервер и с сервера на клиент не самый лучший паттерн, но однако же и не самый плохой. Хуже когда состояния контролов начинают хранить в сессии. Негативных моментов масса - не буду их здесь перечислять.

> Hidden поле чем хуже?
Тем что:
1. Для него нужен unique form id
2. Для него нет контроля допустимых значений
3. На группе hidden полей получается более complicated логика.

> И главное - оно проще чем вьюстейт.
Проще - нет. Стандартней - да. Привычней - да.

> Ведь чтобы записать его во вьюстейт надо контрол,
Нет не нужен. Viewstate'ом можно оперировать как коллекцией.

> получается то же что Hidden поле.
Не то же. Другой паттерн. Другой уровень абстракции. К тому же можно организовать хранение viewstate на сервере и таскание туда/обратно только идентификатора viewstate'а, оставив весь остальной код приложения без изменения.

> не первой загрузке, а при любом POST запросе. Такие запросы -
> редкость.
Все-таки вам следует немного детальнее изучить вопрос.

> Для своих проектов с PHP на С++, ибо нехрена себя баловать. в том чиле и для вебпрожектов. Удобнее будет написать на c++ и подрубить через cgi к апачу. Языки подобные пыху, которые с памятью разбираются сами, банально балуют и делают из программера быдлокодера. мое ИМХО, конечно.

Нехрена баловать кодеров! А то получаются сиплюплюсовые ламеры вроде AiFiLTr0. Реальыне кодеры пишут только в HEX, пишут свою ОС, свои драйвера и свой вебсервер!!! А быдлосишникам процессора 80386 с 1 мегабайтом ОЗУ мало!

>Нет не нужен. Viewstate'ом можно оперировать как коллекцией.

Ок, это забыл. С половиной написанного вами согласен.

>К тому же можно организовать хранение viewstate на сервере и таскание туда/обратно только идентификатора viewstate'а, оставив весь остальной код приложения без изменения.

в форме передается только id вьюстейта, а значения передаются через libastraldotnet.dll ?

>> [Вьюстейт генериуруется] не первой загрузке, а при любом [НЕ] POST запросе. Такие запросы - [НЕ] редкость.

>Все-таки вам следует немного детальнее изучить вопрос.

Аругменты?

> Ути-пути на мозольку наступили?

%^(&$ ^% &$@ :)

> от Ларри письмецо подобное приведи или высказывание.

Щас Ларри взял и обделал свое детище.

>А то тролить все могут.


Ага. Все бросил побежал тебе в гугл искать. Иди и сам ищи. Я это все читал лет пять назад, и писал ту длинную статью никак не Ларри, а может и не разработчики parrot. Ты хоть сам хотя бы в википедию заглянул ?


Wikipedia:
Perl 6 has been under development for over seven years, prompting some commentators[attribution needed] to suggest that Perl 6 may be vaporware.

Рубепетонщецы в треде уже гавкали? :)

нет, тебя ждут. Можно начинать?

>просто python практически никому не нужен

+1

Мечты блондинку дривят :)
Нужен змей - НУЖЕН!

>просто python практически никому не нужен

час назад вместо python было другое слово.. меня глючит?

Почаще надо такие темы постить - треду уже четвертые сутки пошли! :0)

> брать на работу джуниоров - не такой высокий риск, ибо их много.

Абсолютно верно. Но ситуация типа "мидлы готовы сдавать майлстоун, а джуниоры еще учат фреймверк (на живом проекте)" - это как-то не того...
Согласен, можно посадить на внутренний проект под руководство какого-нибудь "дядьки Черномора" и потратить на это энное количество времени, но оно нам надо?
Мы делаем так в некоторых случаях, но поступать так постоянно...

> И вот не надо о правильном и грамотном применении пхп, договорились? В качестве примера заставьте его хотя бы научиться сравнивать объекты. Чтобы не получалось вот так: http://www.krupenik.com/bugs/php/2007121101.phps

Абсолютно согласен - в пыхе много дыр и архитектурной кривости, но опять же повторюсь: в руках опытного разработчика - это ПРИЕМЛЕМЫЙ по возможностям инструмент. А знать обо всех этих минусах и по максимуму их нивелировать - это задача этого разработчика, и люди опытные с этим вполне успешно справляются.

> у вас таки странные заказчики. у нас свои pre-production серверы, куда мы выкатываем демки.

Точно. У нас такие серверы тоже есть. И демки туда тоже коммитятся регулярно. Но заказчики действительно бывают странные. Об этом выше хорошо Батарейкин сказал, кажется.

> профессионал по пхп? не смешите, право слово.

Не вижу в этом ничего смешного. Люди опытные, адекватные и здравомыслящие находятся среди специалистов в любой технологии. Вспомните 1С: многие из 1С-ников - бомжи просто. Но вы же не станете говорить, что все специалисты по 1С - поголовные придурки.

> это всё так, да. Но выбор технологии вообще не в компетенции заказчика в 99% случаев. И в SRS пишется не ультимативное решение Самого, а нечто обсуждённое.

Да как вам сказать... Очень часто приходят заказчики с требованием "хочу на ПХП". Мы, конечно, предлагаем и другие варианты, если ПХП для этого не подходит (например, медиа-сервисы - вотчина, преимущественно, .NET). Но окончательный выбор - за заказчиком. И это - нормально, потому что платит именно он.

Так что говорить о чем-то так категорично, как вы. могут многие. Особенно, если "все еще впереди" :0). А порассуждать здраво и принять во внимание конкретные реалии рынка, состояние контор и другие факторы - слабо (к вам, впрчем, это не относится, наверное - вы хоть аргументы привели).

ЗЫ: Посмотрел инфу - так мы, оказывается, земляки! Ну, живы будем! :0)

> А вот пример реальный, и доступный для ВАШЕГО уровня развития: MS Windows* .

А причем тут вообще Виндовс??? Причем тут вин-разработчики (среди них есть здравые, жаль. что мало)???

Речь шла и идет о ПХП.

Прежде, чем газировать лужи, внимательно читайте тред.

> в форме передается только id вьюстейта, а значения передаются через
> libastraldotnet.dll ?
Значения могут оставаться в локальных кэшах, могут передаваться клиенту - это на усмотрение разработчика. Причем даже при сохранении значений локально - это все еще не будет сессией.

Viewstate - это не про то, что данные ходят туда/обратно, а про то что у веб-формы есть свое состояние (потому и название viewstate, а не dataPostbackContainer).

То что реализация самая простая и самая частоупотребимая и самая частоадекватная держит данные в виде hidden поля которое гоняет туда-обратно еще не характеристика.

> Аругменты?

Вот это:
------------------------ 8X --------------------------
>Хранить результаты дорогой операции, выполняемой при первой загрузке страницы.
не первой загрузке, а при любом POST запросе. Такие запросы - редкость.
------------------------------------------------------

показывает что вы немного недоразобрались в lifecycle страницы.

>показывает что вы немного недоразобрались в lifecycle страницы.

Ну я не специалист по некрософтным технологиям, может поясните? или же

а) При запросе методом GET, ViewState не теряется?

б) POST запросы в asp.net повсюду?

> Ну я не специалист по некрософтным технологиям, может поясните? или же

Потому я и говорил что лучше немного в изучить тему.

> а) При запросе методом GET, ViewState не теряется?

При запросе методом GET, если форма работает по методу POST, при стандартной реализации ViewState, ViewState формы восстановит значения состояний для внутренних контролов в значения "по-умолчанию". Аналогично тому что происходит в толстоклиентном приложении при закрытии/открытии приложения (опять же если разработчик не позаботился о сериализации состояния формы в какое-нибудь хранилище и десериализации при перезапуске).

У хорошего разработчика ничто и никогда не "теряется". Если вы понимаете поведение системы - она будет вести себя предсказуемо. Если нет - то нет.

При использовании метода GET для формы, значение ViewState будет передано в hidden поле как обычно.

> б) POST запросы в asp.net повсюду?
(ааа POST в asp.net нас окружают - АаааААа! we will die! :) )

Нет не повсюду. Asp.net приложения используют различные методы получения и отправки данных в том числе для http POST и GET.

В приложениях с web forms чаще всего для WebForm приложиния, для отслеживания действий пользователя на текущей форме чаще всего используют POST.

>При запросе методом GET, если форма работает по методу POST, при стандартной реализации ViewState, ViewState формы восстановит значения состояний для внутренних контролов в значения "по-умолчанию". Аналогично тому что происходит в толстоклиентном приложении при закрытии/открытии приложения (опять же если разработчик не позаботился о сериализации состояния формы в какое-нибудь хранилище и десериализации при перезапуске).

Т.е. никакой магии нет, и значение вьюстейта надо хранить в сессии => куки, чтобы оно продержалось.

>При использовании метода GET для формы, значение ViewState будет передано в hidden поле как обычно.

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

Вобщем единственное полезное что я вижу во вьюстейте - простой способ сериализации форм, и эту всю штуку можно запихнуть в базу(профиль пользователя) или в сессию, а потом их восстанавливать. Больше я недоволен не этим, а тем что этот сериализованный объект приходит мне в hidden поле, хотя обратно на сервер не попадает - и я считаю это неоправданным расходованием времени/трафика, разве вы с этим не согласны? Я говорю про случай на главной странице http://asp.net

Остальное все прекрасно понимаю, прочитал статью про lifecycle страницы asp.net - ничего нового не узнал. Все так, как я догадывался ранее.

> Т.е. никакой магии нет, и значение вьюстейта надо хранить в
> сессии => куки, чтобы оно продержалось.

Редкий LORовец дочитает предложение до середины. Еще раз по буквам. Сессия тут не при чем. Ну и в общем дальнейшие объяснения по тарифу $150/час.

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

То есть вы хотите меня убедить в том, что глупость, которую вы морозите 4ый раз - это истина? Прочитайте что вам написано. То что вы сейчас в очередной раз написали - это глупость. Черезмерно поверхностное суждение.

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

Единственную пользу от дальнейшего обсуждения вижу в материальном вознаграждении. Если собеседник продолжает настаивать на глупости, которую морозит - пусть хоть платит за то что мне ее приходится слушать.
Тариф я уже обозначил $150/час.

> и я считаю это неоправданным расходованием времени/трафика, разве
> вы с этим не согласны?

согласен. интернет у меня безлимитный, а время как раз и стоит $150/час.

> Остальное все прекрасно понимаю, прочитал статью про lifecycle
> страницы asp.net - ничего нового не узнал. Все так, как я догадывался
> ранее.

Гляжу в книгу - вижу фигу.


PS: Если обидел - прошу прощения. Ничего личного.

Да, я понял что вы некомпетентны в этом вопросе, и свои заблуждения вы считаете истиной. Мне жалко тех идиотов которые платят деньги за разговор с вами, это как быдлопреподы в институте, которые учат бреду.

Вы не способны донести свои мысли и понять мои. Возможно вы даже не знаете протокол HTTP. Я думал дотнетчики не поголовно такие глупые, но если они утверждают что значения hidden полей передаются при запросе методом GET то это диагноз.

>Я думал дотнетчики не поголовно такие глупые, но если они утверждают что значения hidden полей передаются при запросе методом GET то это диагноз.

А как ещё, по-твоему?? :)

http://balancer.ru/files/0712/form.html - введи чего-нить и нажми на кнопку. Любуйся в строке адреса.

>А как ещё, по-твоему?? :)

Черт. Не то, я имел ввиду без отправки форм.. Вобщем:

Если я захожу на http://aps.net мне приходит hidden поле. После того как я нажимаю на ссылку <a href="/downloads/"> то значение этого поля никуда не передается. Дотнетчик утверждает что передается.

Ну и если вы видели что за вьюстейт то сразу поймете что передавать его через параметры в URL - идиотизм. URL должен быть предельно коротким и понятным.

И еще скажу - вот вы показали нормальный пример и мы друг друга поняли. А дотнетчик просто уходит от вопроса, посылает читать книги (которых видимо он сам не читал). Потом начинает разводить понты про 150$/час, видимо по делу сказать не может ничего.

>то значение этого поля никуда не передается. Дотнетчик утверждает что передается.

Так, может, у них просто в куках id сессии, а с точки зрения движка это поле сидит в этой самой сессии?