Затем что проблемы у так себя называемых новичков возникают из-за старья, которое они достают невесть откуда, окапываются в нем и пополняют такого вот рода базы данных как этот форум своими несуразными вопросами. Считая и себя новичком хотел бы поделиться своим пониманием со страдальцами и "желаю чтобы все". Амбула. Достаточно почитать такую, например статью - http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller - чтобы ничего не понять, плюнуть на заморочки и продолжать строгать лапшу. Там и картинка есть, типа иконы святой троицы MVC - молись, ибо непостижимо, верь ибо абсурдно. Почему-то у программистов не складывается литературный контент. Может у меня сложится. Сперва термины - модель это контент, содержание. Вероятно из-за широкого применения баз данных об этом забывают упоминать, или считают само собой разумеющимся. Содержание рождается в модели откуда бы оно в нее не бралось, в том числе из мозга программиста, заказчика или начальства программиста. Код (Text): /model/hello.php $a='Hello'; // создано содержание /model/world.php $b='World'; // создано содержание /model/exclamation.php $c='!'; // создано содержание Глагол model по-английски - конструировать. Содержание конструируется в контексте задачи поставленной перед программистом, следовательно логика наряду с содержанием рождается именно в модели. Тут следует отметить что данные и логика обработки данных (процедуры) - тоже данные. Нет ничего в мире информации кроме данных. Просто одни данные используются для создания других данных, в свою очередь другие данные создают еще более другие. Все это вместе называется информацией. Человек - единственное животное на Земле способное производить информацию. То есть любые данные включают в себя логику по которой они были созданы и можно тогда сказать что все данные - это процедуры (средства). Аналогия с инструментом - инструмент создается чтобы сделать другие инструменты, станки, станки с ЧПУ, станки-роботы и тд. Так вот по терминам. Заменив слово-кальку "модель" на слово "содержание" мы сразу проясняем смысл другой части шаблона программирования MVC - View - который по-русски принято называть "Представление". Что обозначают модель-представление? ХБЗ. А вот парочка Содержание-Представление - вполне сами себя объясняют. Итак, модель - это содержание и эквивалентная логика формирования данного содержания. будет продолжено... Добавлено спустя 20 секунд: Идеальным языком хранения содержания признан XML, поскольку он структуирует Содержание, но никакого Представления сам не несет. Представление на него одевается как офисный дресс-код на сотрудника днем, или клубный дресс-код на сотрудника вечером, или порно-дресс-код на сотрудника ночью. Однако XML не нашел широкого применения именно из-за трудностей декорирования его структуры. Которые несомненно были бы решены в условиях достаточного спроса на технологию. Но спроса не было, соответственно в разработки не вкладывались и все средства остались в академическом, непостижимом для нормального программиста доступе. К слову технология SVG основанная на XML утверждалась 15 лет и все равно лишь редкая птица долетит до середины path. Все остальное что служит конструированию содержания - нелепые контроллеры, всякие там роутеры-шмоутеры - никакого отношения к шаблону (паттерну) программирования на самом деле не имеют. Это сервисы которые лишь облегчают задачу программиста по конструированию содержания. Контроллера может не быть вообще. Ну вообще никакого. Роутер - без него никак в динамическом конструировании, но слово Роутер и не фигурирует в акрониме MVC. Таким образом остается Содержание и Представление - все как завещали XML+XSL. А на картинке на википедии нарисована полнейшая хрень. Дело не в обмене между компонентами, а в обмене между моделями - между кусками содержания и кусками логики этого содержания. Как именно Представление получает Содержание - впихивают ему, или оно вытягивает (push/pull) - не важно. Как подключаются куски содержания, через роутер, контроллер, карбюратор или коллайдер - не важно. Как угодно. Важно вот что: Императив. Представление не имеет права появляться до того (а не там) пока конструирование содержаения не закончено. Представление представляет содержание после (а не там) когда вся основная работа в слое Конструирование содержания (в модели) закончена. Код (Text): /model/a5.php include /model/b3.php $w = $a . $b; include /model/exclamation.php $w .= $e; return $w; // somewhere within router include /view/w.php <h1><?php echo $w; ?></h1> Другими словами все файлы из папки model могут возиться между собой сколько угодно в целях исполнения воли заказчика, а потом файл из папки /view все что они навозили покажет. Но если сделать наоборот, если начать что-то показывать сразу, все из 1 файла, то он, и вообще все они - мгновенно превращаются в неконтролируемую кучу слипшейся лапши. Вот в модели захотели поменять содержание: Код (Text): /model/a5.php include /model/b3.php $w = $b .' is died,' . $a . ' moron'; include /model/exclamation.php $w .= str_pad($e, 100); return $w; // somewhere within router include /view/w.php <h1><?php echo $w; ?></h1> Вместо Hello World! - World is died, Hello moron!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Хотите сказать элементарный уровень? Так и есть. Но почему-то находится изрядное количество читателей которые не согласившись сдаться какому-нить фрейморку - куда MVC уже встроен и его не избежать - чертят чудовищный чертеж обхода сонмы внезапно вылезающих условий в своих безраздельных файлах. Всему есть капец и такое конструирование лапши очень быстро заканчивается. Сайт прекращает жить, то есть развиваться. Ну вот, а конкретная реализация может быть какой угодно. Самое простое, если вам не жалко файлов - устроить роутер и без контроллерно аттачит файлы, которые будут аттачить файлы, которые будут и так далее согласно древовидной структуре гипертекста. Собственно из-за которой и все проблемы. Он как бы текст, но в то же время гипер - внутри одного текста есть еще текст, внутри еще текст, еще по бокам текст, и все такое. Это было изобретение и мы им пользуемся, но понимают его суть не все. В общем делите свои файлы на 2 части - на часть которая загружается ДО и часть которая загружается ПОСЛЕ и будет вам счастье. Или пишите классы в которых соединены обе этих части, но вызывайте методы из разных частей только ДО и ПОСЛЕ согласно категорическому императиву не рендерить из конструирования, и не конструировать в рендере. Будет продолжено.
Меж тем 1980й год уже 35 лет как кончился... Меня(в том числе как человека, работающего в медиапроизводстве) всегда умиляло то, что PHPшники любят говорить про рендер. Собрать верстку для отдачи браузеру - это не рендеринг. Рендеринг это то, что делает с версткой браузер. Сборка страницы есть сборка страницы. Не рендер это ни разу.
И это очень печально, когда программисты, делающие "многие известные фреймворки", используют терминологию, значения которой не знают.
странно. рендер это визуальная отрисовка модели. почему натягивание гандона представления на данные модуля нельзя назвать рендером?
Потому, что ты готовишь текст к отправке, а отображет оный собственно "создает картинку" уже браузер, и тут с сурикатом согласен я, тоже задумывался чего это с фантазией у создателей, но как-то отмахивался, типа ну назвали и назвали.
нет уж. есть какие-то данные. переменные модуле сайта или 3д модель самолета. они по сути бесполезны без приложения которое выведет их в корректном виде - вью или вьювера. когда контроллер соединяет данные модуля с нужным шаблоном происходит то же самое что и когда вьювер читая математику 3д модели выводит графическое представление. теперь с другой стороны. шаблон и как и вьювер будут совершенно бесполезны без входящих данных - переменных или 3д модели. таким образом совсем не вижу почему нельзя заполнение шаблона называть рендером. тот же хрен с браузером. он не будет рендерить пока вы ему не дадите хтмл-исходник. и хтмл исходинк будет бесполезным набором байт без программы которая его представит в визуальном виде - браузера. либо мвц использует рендер либо браузер рендер не использует))) Добавлено спустя 9 минут 15 секунд: у тебя (контроллера) есть шкаф из икеи (модел) и инструкция по сборке (вью) - ты асемблируешь фурнитуру у строительной бригады (к) есть стройматериалы (м) и проект здания (в) - они констряктят билдинг у повара (к) есть продукты (м) и рецепт (в) - он мейкает фуд (или мил, хер знает, жрачку короче) мне кажется можно много чего придумать из реальной жизни как называть подготовку текста к отправке. кстати совсем не обязательно текста, так ведь? и совсем не обязательно отправке. верно?)))
То, что в 3D модлировании слово render имеет иной смысл еще не значит, что в генерации страницы оно не должно применяться Слово это используется во множестве контекстов. Из словаря: "He renders Mozart in a very original manner."
Ох...окей. Не буду придираться к техническому пониманию, ибо пофиг. То, что ты назвал "математикой 3д модели" и есть собранная страница. Сохранение модели в файлик, описывающий ее вершины и связи между ними, это не рендеринг, а, внезапно, сохранение модели. Или подготовка, если угодно. Рендеринг, это когда эти данные визуализируются как-либо. Сборка страницы - это и есть подготовка того самого файлика, описывающего модель. А рендерит его совсем другая программа, то бишь браузер. assembly() - это в миллион раз точнее Рендеринг как термин используется не только в графике. Когда ты обсчитываешь видео после обработки, это тоже рендеринг. Даже когда ты из какого-нить кубейса вытаскиваешь музло в мп3-шку, это тоже рендеринг. Предлагаю не путать глагол "to render" и термин "rendering". Слово "render" не имеет к рендерингу никакого отношения. Это в русском языке оно так закрепилось. И даже огромный есть сайт, посвященный графике render.ru, но правильное название для описания того, кто занимается "представлением" некоей описанной сущности не render, а renderer.
Столько всего излито и непонятно зачем. Чего хотел автор, нащупать единственное верную истинную жилу в веб-проектировании? Её нет и искать совершенно бесполезно. В каждом конкретном серьёзном нагруженном проекте, в каждом модуле этого проекта могут быть особенности и требования которые сводят на нет все популяризируемые подходы к проектированию. И очень часто может возникать ситуация когда конкретные запросы нужно отрабатывать в обход всяких mvc и прочих парадигм. Да и авторы концепции никогда не претендовали на её универсальность и не проповедовали следование ей как жёстким правилам в разработке. Это всего лишь рекомендации, следуя которым и авторам программы и последующим её разработчикам будет легче и быстрее в ней разобраться, развивать и улучшать проект. Это совершенно не означает преимуществ с позиции скорости выполнения кода, точно также как это не означает преимущества в скорости ООП-кода приложения в сравнении с кодом на процедурном стиле оптимизированным под скорость выполнения. Это всего лишь рекомендация. И совершенно не нужно говорить с высока и пафосно как нужно правильно трактовать эту парадигму. Что делать а чего не делать. Не нужно быть из тех программистов, которые приходят в офис работать над чужим проектом и, потратив месяц на его изучение, выссказывать работодателю каким плохим был ваш предшественник и как нерационально он подошл к ршению задачи, и как всё у него не по mvc-феншую. Не забывайте среди прочего, что ваш предшествнник мог потратить времени на написание всего этого кода меньше чем вы на его изучение и переписывание в соответствии со своими представлениями о его идеальной структуре. Точно также может возникнуть необходимость обходить в обработке запросов стандартную логику фреймворка в угоду скорости выполнения и вызывать ту же вьюху из модели либо вообще не иметь ни первого ни второго. Вы понятия не имеете о том в какие временные рамки и требования был поставлен предшественник, и считать что его подход ошибочен потому что он не такой изящный как у вас, такого пафосного теоретика, по меньшей мере опрометчиво. Сегодня многим можно пожертвовать в угоду скорсти написания кода, а если он в итоге исполняется ещё и быстрее чем код структурированный строго по парадигме исповедуемой фреймворком то скажу так - всем будет начехать на то, как он у вас написан. Особенно если он быстрее выполняется. И даже если последнее условие не соблюдается, иной раз легче доставить одну планку опереративной памяти в мат-плату сервера или слить php-код в С и приступить к другому модулю, чем неделями пафосно рассуждать какую экономию ресурсов можно получить поставив одинарные кавычки или как удобно будет потом работать с кодом отделив контроллер от представления.
я как программист, пишу приложение, которое работает в своем окружении и в своей логической и структурной связи. Тут есть свои уровни работы приложения. в процессе создания отображения страницы, я вытаскиваю данные, подготавливаю их , натягиваю шаблон и отдаю браузеру(т.е. рендерю). рендер страницы происходит даже у меня в голове, еще перед тем как увижу результат в браузере. ибо я уже представляю как это должно выглядеть на основе именно этой html разметки. получается на моем уровне(исполнения приложения на сервере) это именно рендер(т.е. я УЖЕ знаю как это будет/должно выглядеть). Где это там будет показано В ИТОГЕ, меня уже не касается. Хоть в камне, скульптор на основе разметки, вырежет. это уже будет рендер для клиента. и итог для клиента зависит от того насколько он будет соответсвовать спецификациям и версиям w3c. пример. Я - создавая разметку, делал всякие фишки для версии IE8+, и мой мысленный рендер показал мне один результат. а Клиент открыл сайт через IE3, и у него будет совсем другой рендер. совсем не тот который должен быть. или может моя страница вообще для анализа роботом(API,вебсервис и т.д.) . тут браузер вообще боком. поэтому название вполне удачное. главное что интуитивно понятное.
Это бесспорный аргумент. Жаль, что это не форум философов, обсуждающих сущность бытия и понятия что есть реальное представление сущности. Суть терминов в том, что они не метафоричны. Они не зависят от твоего их понимания и видения. Се ля ви. https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%BD%D0%B4%D0%B ... 0%BD%D0%B3 Если перенести на язык графики, то твоя подготовка верстки - это сборка сцены. Вот тут свет, вот тут такие-то объекты, на них такие-то материалы, под материалом такие-то текстуры, фон такой-то, и тд и тп. Метаданные. Разметка. А рендером для нее выступает браузер. Собирает данные, которые ты дал, и превращает их в красявый вполне себе такой визуальный результат. Я тоже могу представить кадр мультика, глядя на болванчиков в сермате на фоне планки с ненатянутым фоном. Это называется воображением. Люди они такие, могут воспроизводить в голове даже не существующие образы, строя их только на основе неких внешних данных, знания структуры или описания. Книги так работают не первое столетие. Но рендеринг - это когда программа генерит реальные кадры, которые могут увидеть другие люди.
вот это аргумент. а вот это нет. мой сурс доступен всем, кто умеет делать вью сурс в своем браузере =) 1-1 почему-то...
и всё. цель достигнута. программа нагенерировала в общем я до сих пор не увидел почему использование термина рендер является недопустимым. зато логику почему допустимо - пяток раз показали.
При чем тут то, что браузеры умеют показывать исходный код страницы-то? Или это и есть то, что по-твоему нарендерил пых? Ну, если ты совсем на графику хочешь параллели перевести, то перед рендерингом сцена конвертится в файл, понятный програме-рендеру, содержащий описание объектов, их свойств и тд. А потом уже на основе вот этих данных обсчитывается картинка. А то дело какое, рендер, mental ray, например, один, а пакетов с ним дружит много, и у всех формат хранения сцены свой, а дружить нужно. Именно за счет того, что в пакет включена библиотека, умеющая скармливать менталу сцену в понятном ему виде и принимать от него ответ. Считай, что это и есть то, что нагенерил пых для браузера. Рендеринг - процесс визуализации. Компоновка текста для отправки браузеру - это компоновка текста для отправки браузеру. Вот когда пых будет страничку отрисовывать и стримить в браузер, то тогда можно смело говорить о том, что рендеринг осуществлен на стороне сервера.
Разумна, когда ты делаешь ее в рамках своей архитектуры и делаешь с умом, а не "как в примере, 1-в-1, а то получится не тру", через боль и костыли. Нет, еств. Можно сделать процедуру-контроллер, которая будет генерить модель и отдавать процедуре, отвечающей за сборку вьюхи. Все одном файле. Логическое разделение есть? Есть. Всеу. Тут, как и с любым инструментом и паттерном важно не уметь повторять-как-у-дяди-чтобы-работало-круто, а понимать смысл. Реализация уже зависит от архитектуры, окружения, требований.
давай представим на секунду, что Пых умеет это делать(отрисовывать и стримить). что измненится для программиста? - а ничего! тоесть, на уровне разработчика, он в любом случае будет готовить данные и заворачивать их в разметку. на его уровне это и есть Рендеринг. ты очень прямолинейно пытаешься сравнивать это с 3Д рендерингом сцен. конечно тут есть отличия. и ты почемуто думаешь что мы этого не понимаем. все мы понимаем. мысли шире! мы тебе о другом говорим. для нас это именно визуализация. так нам проще, понимаешь? интуитивно понятно. это индикатор того что всё, финал. отдаем результат клиенту. ведь по сути при создании страницы будут создаваться отдельные блоки, виджеты, подстраницы.. ЭТО ещё не рендер, а как раз assembly. а вот когда готова вся страница - то остался только рендер. вот мы его и делаем) все логично.
Blyat'. Тот факт, что ты описал див и пришляпил на него CSS-ку не является рендером. Потому что те же тени каждый сраный браузер до сих пор отображает по-своему. Как захочет клиент, так и отрендерит твою страницу. Или не отрендерит вовсе. Ты не страничку посылаешь клиенту, не формочки, не кнопочки. А буковки. Которые говорят ему, мол вот тут нарисуй мне кнопку, а покрась ее вот так-вот, если сможешь, конечно. С тем же успехом можно говорить, что код шейдера - это его рендер, потому что программист графики, глядя в него, может представить себе материал, который в нем описывается. Во, примерчик: Код (Text): Shader "Bumped Anisotropic Specular" { Properties { _Color ("Main Color", Color) = (1,1,1,1) _MainTex ("Diffuse (RGB) Alpha (A)", 2D) = "white" {} _SpecularTex ("Specular (R) Gloss (G) Anisotropic Mask (B)", 2D) = "gray" {} _BumpMap ("Normal (Normal)", 2D) = "bump" {} _AnisoTex ("Anisotropic Direction (Normal)", 2D) = "bump" {} _AnisoOffset ("Anisotropic Highlight Offset", Range(-1,1)) = -0.2 _Cutoff ("Alpha Cut-Off Threshold", Range(0,1)) = 0.5 } SubShader{ Tags { "RenderType" = "Opaque" } CGPROGRAM struct SurfaceOutputAniso { fixed3 Albedo; fixed3 Normal; fixed4 AnisoDir; fixed3 Emission; half Specular; fixed Gloss; fixed Alpha; }; float _AnisoOffset, _Cutoff; inline fixed4 LightingAniso (SurfaceOutputAniso s, fixed3 lightDir, fixed3 viewDir, fixed atten) { fixed3 h = normalize(normalize(lightDir) + normalize(viewDir)); float NdotL = saturate(dot(s.Normal, lightDir)); fixed HdotA = dot(normalize(s.Normal + s.AnisoDir.rgb), h); float aniso = max(0, sin(radians((HdotA + _AnisoOffset) * 180))); float spec = saturate(dot(s.Normal, h)); spec = saturate(pow(lerp(spec, aniso, s.AnisoDir.a), s.Gloss * 128) * s.Specular); fixed4 c; c.rgb = ((s.Albedo * _LightColor0.rgb * NdotL) + (_LightColor0.rgb * spec)) * (atten * 2); c.a = 1; clip(s.Alpha - _Cutoff); return c; } #pragma surface surf Aniso #pragma target 3.0 struct Input { float2 uv_MainTex; float2 uv_AnisoTex; }; sampler2D _MainTex, _SpecularTex, _BumpMap, _AnisoTex; void surf (Input IN, inout SurfaceOutputAniso o) { fixed4 albedo = tex2D(_MainTex, IN.uv_MainTex); o.Albedo = albedo.rgb; o.Alpha = albedo.a; o.Normal = UnpackNormal(tex2D(_BumpMap, IN.uv_MainTex)); fixed3 spec = tex2D(_SpecularTex, IN.uv_MainTex).rgb; o.Specular = spec.r; o.Gloss = spec.g; o.AnisoDir = fixed4(UnpackNormal(tex2D(_AnisoTex, IN.uv_AnisoTex)), spec.b); } ENDCG } FallBack "Transparent/Cutout/VertexLit" } Для тебя это такая же китайская грамота, как для юзверя твои HTML-ки и CSS-ки, которые ты рендеришь в своем воображении. Именно твое воображение тут является рендером, а не пых. Ты смотришь в код и знаешь, как выглядят элементы и можешь их представить. Браузер делает то же самое. Мысли объективно, а не защищай моду на нейминг, который самозародился из-за чьей-то безграмотности и того факта, что "рендеринг" звучит-таки прям круто и технологично. Иии...что?