Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
Алексей КВ нашем случае всё должно держаться исключительно на технических характеристиках. ... и здравом смысле :) Алексей КМСУпропущено... И пусть используется.Ну всё, теперь я спокоен на все 100. Ну вот, как хорошо, что я зашел :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 15:19 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
МСУАлексей Кпропущено... Ну всё, теперь я спокоен на все 100. Ну вот, как хорошо, что я зашел :)Лучше поздно чем никогда. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 15:22 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
Алексей КЛучше поздно чем никогда. :-) Честно говоря, я даже не понимаю, зачем тебе автофак в этом примере. Родного IDependencyResolver с головой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 15:26 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
МСУАлексей КЛучше поздно чем никогда. :-) Честно говоря, я даже не понимаю, зачем тебе автофак в этом примере. Родного IDependencyResolver с головой.Ну там InstancePerRequest и прочие ужасы. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 15:29 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
Алексей КНу там InstancePerRequest и прочие ужасы. :-) Вот http://codearticles.ru/articles/2301 На все случаи жизни, коих 99.9% ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 15:34 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
МСУАлексей КНу там InstancePerRequest и прочие ужасы. :-) Вот http://codearticles.ru/articles/2301 На все случаи жизни, коих 99.9% Верю. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 15:43 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
Алексей КНо посмотрим, может в этот раз произойдёт чудо. Я так понимаю, чем больше канючить по этому поводу, шансы на чудо увеличатся? Алексей КИ вообще. Ну не получается если полноценным DI, ну есть же CommonServiceLocator. Почему он не используется в MVC и API? Почему там свои локаторы? Потому что их ничего не связывает в принципе, они работают на разных уровнях, соответственно у каждого свой локатор. WebAPI не зависит от MVC, следовательно от его DependecyResolver, и наоборот. По-моему всё совершенно логично. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 15:56 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
МСУВот http://codearticles.ru/articles/2301 На все случаи жизни, коих 99.9% Примерно тоже самое мне говорил один старый бородатый Си-шник. Говорил, а нахрена мне эти ваши ООП-шные говно-приблуды упёрлись? Виртуальность легко реализовывается на Си, как два пальцо об освальт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 15:58 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
hVosttАлексей КНо посмотрим, может в этот раз произойдёт чудо. Я так понимаю, чем больше канючить по этому поводу, шансы на чудо увеличатся? Шансы увеличатся, если будет конкуренция. На платформе .Net Framework её к сожалению нет. hVosttАлексей КИ вообще. Ну не получается если полноценным DI, ну есть же CommonServiceLocator. Почему он не используется в MVC и API? Почему там свои локаторы? Потому что их ничего не связывает в принципе, они работают на разных уровнях, соответственно у каждого свой локатор. WebAPI не зависит от MVC, следовательно от его DependecyResolver, и наоборот. По-моему всё совершенно логично.Я про отдельный Common ServiceLocator. После выделения MVC и API из стандартных библиотек .Net Framework в этом нет ничего невозможного. Надеюсь, после полноценного перехода на овен всё это будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 16:08 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
hVosttПримерно тоже самое мне говорил один старый бородатый Си-шник. Говорил, а нахрена мне эти ваши ООП-шные говно-приблуды упёрлись?Фанатичная тяга к расширяющим методам в новых библиотеках в чём-то подтверждает его правоту. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 16:13 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
Алексей КЯ про отдельный Common ServiceLocator. Такого в принципе быть не может. Это связано с областью времени жизни, которые в MVC и WebAPI привязаны к разным контекстам, и они никак не коррелируют. Алексей КШансы увеличатся, если будет конкуренция. На платформе .Net Framework её к сожалению нет. Зачем плодить конкуренцию на одной платформе? Надо развивать единую экосистему, и развитие идёт полным ходом, так что всё нормуль. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 17:00 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
Алексей КФанатичная тяга к расширяющим методам в новых библиотеках в чём-то подтверждает его правоту. Фанатичная тяга к ХХХ (подставить сюда что угодно) -- ето плохо и вредно. Этот постулат ничего не объясняет и ничего не доказывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 17:02 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
hVosttАлексей КЯ про отдельный Common ServiceLocator. Такого в принципе быть не может. Это связано с областью времени жизни, которые в MVC и WebAPI привязаны к разным контекстам, и они никак не коррелируют.К каким к разным? Дешёвая обёртка . hVosttАлексей КШансы увеличатся, если будет конкуренция. На платформе .Net Framework её к сожалению нет. Зачем плодить конкуренцию на одной платформе? Надо развивать единую экосистему, и развитие идёт полным ходом, так что всё нормуль.Это не развитие, это тыканье-мыканье. Всё делается методом проб и грубых ошибок. Это не развитие, это деградация. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 17:17 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
Алексей КК каким к разным? Дешёвая обёртка . это заговор! Алексей КЭто не развитие, это тыканье-мыканье. Всё делается методом проб и грубых ошибок. Это не развитие, это деградация. Да, но ты им только ничего не говори! И тем более, ничего не советуй, а то ещё всё поймут и сделают внезапный скачок в развитии Короче, ниачём. Наезд, как обычно, не обоснован ничем. А нравится-ненравится, -- это лучше обсудить с блондинками на женском форуме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 17:31 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
hVosttМСУВот http://codearticles.ru/articles/2301 На все случаи жизни, коих 99.9% Примерно тоже самое мне говорил один старый бородатый Си-шник. Говорил, а нахрена мне эти ваши ООП-шные говно-приблуды упёрлись? Виртуальность легко реализовывается на Си, как два пальцо об освальт. Я стараюсь дистанцироваться от нагромождения, лишних слоёв и абстракций. Основной аргумент - вот когда потребуется развязка, тогда и сделаем это. Тем более, это будет сделать очень легко, т.к. изначально пишется расширяемый код. Плюсы такого очевидны, я быстро поднимаю рабочее приложение без шелухи и оно начинает внятно работать, обрастать функционалом. Но можно пойти другой дорогой, накручивать слои, долго и упорно размышлять о правильности и нужности различных слабых связей, строить стены и ломать мосты. При таком подходе на выхлопе тоже получается рабочая программа. В силу фанатичности второй способ более критичен к времени реализации. Причем, еще раз подчеркну, что в любое время из первого способа можно получить второй приложив минимум усилий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2014, 18:03 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
hVosttАлексей КЭто не развитие, это тыканье-мыканье. Всё делается методом проб и грубых ошибок. Это не развитие, это деградация. Да, но ты им только ничего не говори!Они не поймут. Они живут в каком-то своём мире, на своей планете странных людей. Видел как-то на форуме общение авторов EF с недовольным пользователем. Им было предложено сделать public класс ExpressionVisitor, он тогда был internal. Ответом было, с изрядной долей высокомерия: "Захотим - сделаем, но сначала посмотрим на твоё поведение". И о чём с ними разговаривать? Судя по результатам, там многие такие. hVosttИ тем более, ничего не советуй, а то ещё всё поймут и сделают внезапный скачок в развитии Не переживай, не поймут. Там, как ты сказал, "хороших программистов" нет, обращаться не к кому. Следствие кадровой политики в условиях разрухи, которая преобладает в головах руководства. Один Хейльсберг за всех хреначит, но один в поле не воин. hVosttКороче, ниачём. Наезд, как обычно, не обоснован ничем. А нравится-ненравится, -- это лучше обсудить с блондинками на женском форуме.Было приведено достаточно фактов. Но согласен, блондинок факты не интересуют. Не обижайся. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2014, 05:52 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
hVosttАлексей КФанатичная тяга к расширяющим методам в новых библиотеках в чём-то подтверждает его правоту. Фанатичная тяга к ХХХ (подставить сюда что угодно) -- ето плохо и вредно. Этот постулат ничего не объясняет и ничего не доказывает.Я и не пытаюсь никому ничего доказывать. Это занятие неблагодарное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2014, 05:55 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
Алексей КБыло приведено достаточно фактов. Но согласен, блондинок факты не интересуют. Не обижайся. :-) Чот не заметил. Наезд из области, почему бы на весь .NET не сделать один большой ServiceLocator. Если тебе он так нужен, сделай свой -- в чём сложности? Всем не угодишь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2014, 06:20 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
МСУЯ стараюсь дистанцироваться от нагромождения, лишних слоёв и абстракций. Основной аргумент - вот когда потребуется развязка, тогда и сделаем это. Тем более, это будет сделать очень легко, т.к. изначально пишется расширяемый код. Плюсы такого очевидны, я быстро поднимаю рабочее приложение без шелухи и оно начинает внятно работать, обрастать функционалом. Но можно пойти другой дорогой, накручивать слои, долго и упорно размышлять о правильности и нужности различных слабых связей, строить стены и ломать мосты. При таком подходе на выхлопе тоже получается рабочая программа. В силу фанатичности второй способ более критичен к времени реализации. Причем, еще раз подчеркну, что в любое время из первого способа можно получить второй приложив минимум усилий. Согласен, не однократно сталкивался с излишним увлечением архитектурой, когда полезного кода (непосредственно выполняющего задачи) меньше, чем обвязки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2014, 06:22 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
hVosttСогласен, не однократно сталкивался с излишним увлечением архитектурой, когда полезного кода (непосредственно выполняющего задачи) меньше, чем обвязки Программирование ради программирования - не наш метод. Хотя порой затягивает, да :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2014, 11:15 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
Я тут полностью поддерживаю Алексея. Вот был ASP.NET 1.0. Да, корявые WebForms но в то время подобная монструозность была в моде, а архитектура "конвейера" для первой версии была вполне ничего -- простая и понятная. 2.0 -- эволюционные улучшения модели, ущербность которой уже была видна на фоне тех же Django (егойные Middleware в плане простоты, тестируемости и уровня повторного использования рвали ASP.NET'ные IHttpModule'ы и IHttpHandler'ы на тряпки) и Rails (который был не без проблем, но таки уделывал ASP.NET в простоте и скорости разработки). Тогда же появились первые попытки запилить MVC-подобный фреймворк для ASP.NET; кроме Castle MonoRail что-то ничего не припомню -- возможно, были еще. И тут начинается разнос. Уже появился jQuery, фактически заменив собой Prototype и MooTools, а Microsoft запилили свой, ни с чем не совместимый, AJAX Toolkit с лютыми UpdatePanel'ами и прочим ужасом. Первая версия ASP.NET MVC была неплоха, но отставала от "собратьев" -- WebForms Layout Engine, магические строки и т.д. В 2.0 самые одиозные косяки исправили. Начали появляться альтернативные View Engine'ы. Вот тут пора было немного остановиться и выдохнуть. Уже становилось понятно, что в .NET Framework уже, фактически, четыре, грубо говоря, конкурирующих веб-стека: классический ASP.NET, ASP.NET MVC, классические SOAP сервисы и появившийся уже WCF. Первые три -- еще куда ни шло, хотя ASP.NET MVC для целей повышения тестируемости оборачивал "стандартные" классы в свои красивые (по мнению разработчиков) фантики, но в WCF все было, разумеется, свое. Но каток прогресса было не остановить. Начали появляться разновсякие фильтры, атрибуты, аннотации с порой очень хитрыми спецэффектами от взаимодействия. Дублирование конфигов для IIS6 и IIS7. Ад с версиями .NET 4.0/4.5. Дважды перепиленный мембершип, корявые модели провайдеров, сбоку припиленный для нужд NuGet'а App_Start Потом появился Web API со своим HTTP "стеком". Умельцы из OSS-сообщества сочинили Owin (на делегатах, ога), на что Microsoft решила "а пуркуа бы не па" и окуклилась этим единым ASP.NET'ом, несовместимым со всем остальным хозяйством, заново написанной Identity, конфигурированием в хипстерском JSON'е и с совершенно упоротым использованием Extension-методов по делу и без. Ну и где-то там еще с переменным успехом прикручивали EF и прочие другие прибабахи. OData, например. Или "типа REST" в этом WCF. Или свой сериализатор в JSON. Короче говоря, долгие годы от версии к версии мы получали небольшие эволюционные изменения и революционные переписывания отдельных моментов. Последнее делалось вообще без оглядки на прошлый опыт и ошибки. Везде свой (сабжевый) IServiceLocator/IDependencyResolver/еще-какой-модный-паттерн (это при том, что в .NET спокон века был System.IServiceProvider), в каждом фреймворке своя вариация на HttpRequest/HttpResponse, всё те же статические классы и пухлые интерфейсы и горы и горы обвязки. И не факт, что на "The One ASP.NET" всё закончится. Уйдет ScottGu, явится какой-нибудь студиозус и перепилят этот ASP.NET для достижения очередных высших идеалов многомудрых архитекторов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2014, 11:26 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
Нахлобуч, Так это же здорово! Посмотри какая флора и фауна, любо посмотреть! Кроме того, никто никого не заставляет что-то использовать или на что-то переходить. Как отдельные кодили люди раньше на WebForms, так и продолжают кодить. Проекты, запиленные на MVC 3 всё так же актуальны, и большая часть NuGet-пакетов к ним без проблем подходит. Вообще, одно появление NuGet, это уже прорыв небывалый. Как глобальные репозитории, так и локальные. Что касается OWIN, Майкрософту необходимо было найти выход из стойла ASP.NET, чтобы оседлать другие платформы (Linux, OS X), и OWIN для этого хорошо подходит. Не надо думать, что это просто потому, что кто-то дескать сочинил, а потом "а пуркуа бы не па" -- это похоже на мышление маленького ребёнка. Ничего не делается просто так. Вообще эволюция, любая, какая бы она ни была, всегда идёт по пути экспериментов, через череду неудач. Я знаю как бы многим наивным чукотским парням хотелось: чтобы всё, сразу и идеально. В загробном мире, может быть, но не в реальном. Это нытьё по поводу того, что кто-то там, дескать, как-то не так сделал... Как обычно, забыли самого умного спросить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2014, 11:58 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
Честно говоря не понимаю нытья по поводу платформы и её развитии. Ну развивается себе песочница, кроится на части, эти части стыкуется в единый пирог или поставляются в двух пирогах. Ну и чего. По поводу мембершипов вообще детский сад, тем более про способы написания провайдеров. Лично мне как-то фиолетовы способы реализации мембершипов майкрософтом. Пусть хоть раком пишут или на корачках. Есть родной функционал - беру и использую. Будет новый vnext, будем использовать его в новых проектах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2014, 12:12 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
hVosttТак это же здорово! Посмотри какая флора и фауна, любо посмотреть! Проблема тут двоякая. С одной стороны, в .NET не так развита культура OSS-проектов (достаточно посмотреть на статистику на том же ГитХабе). А с другой, есть некая неприязнь к не-Microsoft проектам, когда какую-то библиотеку отказываются использовать только потому, что она не поставляется вместе с .NET или Visual Studio. И наоборот, отдается предпочтение заведомо более "ущербным" "встроенным" аналогам. hVosttВообще, одно появление NuGet, это уже прорыв небывалый. Как глобальные репозитории, так и локальные.Ага, только прорыв этот локального масштаба -- весь прогрессивный мир менеджеры пакетов использует уже если не десятилетиями, то годами. И новые появляются . И к вопросу о неприязни не-Microsoft проектов: NuGet -- далеко не первая попытка создания менеджера пакетов для .NET. NuGet вырос из Nu, который разработали какие-то совершенно несвязанные с Microsoft чуваки, и этот Nu был одним из многих. Я сам такой писал (и на прошлом месте работы его вовсю использовали). OpenRasta еще был (есть). Еще что-то. Ни один из них не взлетел. И вот только когда Microsoft сказала: "мы тут изобрели революционный тул" -- тогда да, пошло дело. hVosttЧто касается OWIN, Майкрософту необходимо было найти выход из стойла ASP.NET, чтобы оседлать другие платформы (Linux, OS X), и OWIN для этого хорошо подходит.Ой сомневаюсь в желании поддерживать другие платформы. У Microsoft свой стек технологий (начиная от ОС и заканчивая веб-сервером и СУБД) и вот так вот взять и "поддержать Linux"? hVosttНе надо думать, что это просто потому, что кто-то дескать сочинил, а потом "а пуркуа бы не па" -- это похоже на мышление маленького ребёнка. Ничего не делается просто так.Ок, всё делается строго согласно плану и видению, в синергии с остальными подразделениями. Только вот эти планы меняются каждый год. hVosttВообще эволюция, любая, какая бы она ни была, всегда идёт по пути экспериментов, через череду неудач.Бесспорно. Но можно учиться не только на своих, а еще и на чужих ошибках, чтобы каких-то неудач и не допускать. Например, под воздействием каких веществ был рожден неимоверно раздутый MembershipProvider ? Или какой укурок придумал хранить в одном NuGet-пакете сборки для разных платформ и версий .NET Framework? Сколько можно было рожать Middleware (и так толком и не родить)? И давай-ка воздержись от переходов на личности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2014, 12:27 |
|
||
|
OWIN, DependencyResolver
|
|||
|---|---|---|---|
|
#18+
НахлобучПроблема тут двоякая. С одной стороны, в .NET не так развита культура OSS-проектов (достаточно посмотреть на статистику на том же ГитХабе). А с другой, есть некая неприязнь к не-Microsoft проектам, когда какую-то библиотеку отказываются использовать только потому, что она не поставляется вместе с .NET или Visual Studio. И наоборот, отдается предпочтение заведомо более "ущербным" "встроенным" аналогам. Нет никакой проблемы, у майкрософта своя культура, и она имеет все права на неё. На счёт неприязни, не согласен совершенно. У кого-то есть такая неприязнь, у кого-то нет. Я использую коробочные либы, если они решают свои задачи. Если нет, использую сторонние или пишу свои. Конечно в первую очередь я смотрю на то, что есть в коробке, никакой неприязни не испытываю. Проблема надуманная. НахлобучАга, только прорыв этот локального масштаба -- весь прогрессивный мир менеджеры пакетов использует уже если не десятилетиями, то годами. И новые появляются . Не согласен, для открытого репозитария Майкрософт должна была переступить некую свою черту. Им надо продавать, а не помогать распространению халявы. Ты же не работаешь забесплатно, нет? Так почему они должны? Суть прорыва не в новизне, а в самом факте. И это очень круто, я считаю! НахлобучОй сомневаюсь в желании поддерживать другие платформы. У Microsoft свой стек технологий (начиная от ОС и заканчивая веб-сервером и СУБД) и вот так вот взять и "поддержать Linux"? Учитывая определённый успех Линкусов на поприще серверных технологий, Майкрософт не имеет экономического права игнорировать этот факт. Поддерживать не обязана, но и упускать рынок нет смысла. С недавних пор они начали понимать, что не всегда можно перекроить мир под себя, иногда выгодней подстроиться. НахлобучТолько вот эти планы меняются каждый год. Всё течёт, всё меняется. Есть немало людей, включая меня, которых огорчает, что Майкрософт не хватает смелости в очередной мажорной версии .NET очистить платформу от груза и устранить известные косяки в архитектуре, отказавшись от обратной совместимости. Но они же этого не делают? Что касается самой платформы, всё довольно стабильно. Планы меняеются, так как меняются условия, конкруировать есть с чем. НахлобучБесспорно. Но можно учиться не только на своих, а еще и на чужих ошибках, чтобы каких-то неудач и не допускать. Например, под воздействием каких веществ был рожден неимоверно раздутый MembershipProvider ? Или какой укурок придумал хранить в одном NuGet-пакете сборки для разных платформ и версий .NET Framework? Сколько можно было рожать Middleware (и так толком и не родить)? Я очень сомневаюсь, что находясь в самом начале пути, не имея никакого фидбека, нашлось бы много людей, которые могли бы сделать лучше. Лучше -- это всегда сравнительная характеристика. Лучше, это значит есть хуже, а есть лучше. Когда кто-нибудь что-нибудь сделал, легко критиковать, видны чужие недостатки, особенно при наличии более успешных аналогов и с учётом накопленного опыта. Разрабатывать базовую архитектуру очень сложно. То, что сегодня кажется вполне логичным, понятным и удачным решением, завтра может обернуться отвратительным запашком. Я считаю, что достатков гораздо больше чем недостатков, а стремительное развитие, с быстрым отметанием неудачных ошмётков, это восхитительно! НахлобучИ давай-ка воздержись от переходов на личности. Где ты подобное увидел? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2014, 13:12 |
|
||
|
|

start [/forum/topic.php?fid=18&startmsg=38734141&tid=1357027]: |
0ms |
get settings: |
8ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
26ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
80ms |
get tp. blocked users: |
1ms |
| others: | 230ms |
| total: | 380ms |

| 0 / 0 |
