Здравствуйте, sambl74, Вы писали:
S>>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
S>Ну вообще-то он есть — https://ru.wikipedia.org/wiki/SSI_(программирование)
Здравствуйте, Shtole, Вы писали:
S>Какие были инженерные резоны против такого решения?
S>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
есть же document.write
есть же tag.innerHTML | tag.innerText
Здравствуйте, Shtole, Вы писали:
S>Какие были инженерные резоны против такого решения?
S>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
Здравствуйте, vsb, Вы писали:
S>>Какие были инженерные резоны против такого решения?
vsb>Вероятно маленький спрос на такую фичу.
S>>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
vsb>Вероятно не такая уж и изрядная.
Ну уж, футеры-то с копирайтом есть на каждом сайте.
Между прочим, Майкрософт прикрутил колонтитулы к офисным документам очень рано. В 95-м офисе, кажется. И это для сиволапых юзеров. Была, значит, у них потребность в DRY. А тут — инженеры, умеющие в разметку, и у них не возникло потребности в более удобном структурировании на раннем этапе развития HTML? Вот это меня и удивляет.
Здравствуйте, Lazytech, Вы писали:
S>>Все эти теневые деревья убивают саму идею.
L>Напомню, идея в изоляции от остального HTML-кода.
Идея #include в файлизме, как это называл один знакомый. Юниксовая концепция, что всё — в том числе, шаблон для вставки — есть файл. (Там даже устройства — файлы, что уж говорить про шаблоны). Зачем же изолировать вставленный из файла фрагмент? Наоборот, в соответствии с этой концепцией, он должен бесшовно вписаться в DOM. Ну, как это, собственно, и происходит в Си.
Здравствуйте, Shtole, Вы писали:
S>Ну уж, футеры-то с копирайтом есть на каждом сайте.
S>Между прочим, Майкрософт прикрутил колонтитулы к офисным документам очень рано. В 95-м офисе, кажется. И это для сиволапых юзеров. Была, значит, у них потребность в DRY. А тут — инженеры, умеющие в разметку, и у них не возникло потребности в более удобном структурировании на раннем этапе развития HTML? Вот это меня и удивляет.
Здравствуйте, night beast, Вы писали:
S>>Ну уж, футеры-то с копирайтом есть на каждом сайте.
S>>Между прочим, Майкрософт прикрутил колонтитулы к офисным документам очень рано. В 95-м офисе, кажется. И это для сиволапых юзеров. Была, значит, у них потребность в DRY. А тут — инженеры, умеющие в разметку, и у них не возникло потребности в более удобном структурировании на раннем этапе развития HTML? Вот это меня и удивляет.
NB>ну, были всякие frameset, или ты про другое?
Фреймы дают ту самую (непрошенную) изоляцию, обсуждаемую выше. На практике это значит, что (например) нельзя шаблонизировать пол-элемента. Хотя это может быть исключительно сложно устроенный элемент.
Здравствуйте, ·, Вы писали:
S>>Какие были инженерные резоны против такого решения? ·>frame/iframe разве не оно?
S>Фреймы дают ту самую (непрошенную) изоляцию, обсуждаемую выше. На практике это значит, что (например) нельзя шаблонизировать пол-элемента. Хотя это может быть исключительно сложно устроенный элемент.
S>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
Сейчас большинство сайтов собираются программами-сборщиками (WebPack, Vite, gulp — их тьма) из исходников (причем даже статических HTML сайтов). Вот там и делается этот #include из разных исходников с обработкой CSS и рендерингом шаблонов, а также "перетряской дерева" для минимизации размера страницы (и довольно эффективно, если разработчики уделяют этому внимание). При отдаче контента #include не даст пользы (ну, или опиши реальную ситуацию, где #include в HTML по сети с клиента будет полезен).
Здравствуйте, Reset, Вы писали:
S>>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
R>Сейчас большинство сайтов собираются программами-сборщиками (WebPack, Vite, gulp — их тьма) из исходников (причем даже статических HTML сайтов). Вот там и делается этот #include из разных исходников с обработкой CSS и рендерингом шаблонов, а также "перетряской дерева" для минимизации размера страницы (и довольно эффективно, если разработчики уделяют этому внимание). При отдаче контента #include не даст пользы (ну, или опиши реальную ситуацию, где #include в HTML по сети с клиента будет полезен).
Мне больше интересно в ретроспективе. HTML ведь появился очень давно.
Если говорить про то, что сейчас. Сейчас его развивают компании, основной актив которых — сервера. Был бы странно, если бы в него добавили что-то настолько «антисерверное».
S>Мне больше интересно в ретроспективе. HTML ведь появился очень давно.
Я практик и прагматик. Такое мне не интересно.
S>Если говорить про то, что сейчас. Сейчас его развивают компании, основной актив которых — сервера. Был бы странно, если бы в него добавили что-то настолько «антисерверное».
Это типа "у нас много серверов, давайте придумаем что-то, что их нагрузит не по-децки"... Так вряд ли кто-то думает. Сознательно создавать работу для своего оборудования никому не надо. Народ очень хорошо умеет деньги считать.
Здравствуйте, Reset, Вы писали:
S>>Если говорить про то, что сейчас. Сейчас его развивают компании, основной актив которых — сервера. Был бы странно, если бы в него добавили что-то настолько «антисерверное».
R>Это типа "у нас много серверов, давайте придумаем что-то, что их нагрузит не по-децки"... Так вряд ли кто-то думает. Сознательно создавать работу для своего оборудования никому не надо. Народ очень хорошо умеет деньги считать.
Лол. Так что ж они не сделают? Если сборка на клиенте действительно снизит нагрузку.
Здравствуйте, Shtole, Вы писали:
S>Какие были инженерные резоны против такого решения?
Статически подставить можно и на сервере (а это еще и кэширование), а динамически — все равно нужен скрипт, который и так может и include, и более сложную логику.
S>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
На голый html без скриптов? Зачем собирать на каждом клиенте статическую страницу, которую можно было собрать на сервере без всяких пхп, только с SSI/ESI?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Shtole, Вы писали:
S>Какие были инженерные резоны против такого решения?
То, что документ не целостный получается? Да и смысл? Если можно собрать документ
из кусочков в браузере, то почему бы не сделать это сразу? (заранее собрать C-препроцессором)
Если речь же об #include управляемом условиями, данными форм, запросами из БД -- то это другое.
Это явно требует исполнения "скрипта" в браузере. Ну так собственно на JavaScript и можно
сделать "#include" путём XHR-запросов кусочков сайта и ручной их композиции (путём вставки
в нужное место DOM). Более того, если откинуть миллион новомодных фреймворков, то это всё
на самом деле относительно удобно делается на голом JS посредством форм (которые нужны, чтоб
адресовать элементы в DOM, иначе XPath-запросты в queryDocumentSelector писать больно муторно.
S>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
Вот не понял мотивации вообще. Есть же SSI. Только чем он поможет? Как статический "#include"
на стороне сервера он вполне работает (но повторю тезис, тогда документ можно собрать заранее).
А если нужно условное включение кусочков документа -- для этого и есть PHP, который позволяет
собрать статический HTML-документ, отображаемый без JavaScript. Это отличие от подхода описанного выше.
А когда мешают в кучу jQuery/Vue/etc и генерацию статических страниц на PHP -- это от космической дурости.
Тут уж либо статика, либо динамика (javascript на клиенте).
Здравствуйте, ути-пути, Вы писали:
S>>Какие были инженерные резоны против такого решения?
УП>Статически подставить можно и на сервере
Можно и на сервере. Только это требует сервера
Просто у HTML есть огромное число применений, когда никакой сервер в принципе не нужен. А шаблонизация нужна. Иногда можно выкрутиться фреймами, иногда — скриптами, но всё это чертовски неудобно по сравнению с обычной подстановкой, и я не понимаю, почему в самом начале такую возможность не предусмотрели.
S>>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
УП>На голый html без скриптов? Зачем собирать на каждом клиенте статическую страницу, которую можно было собрать на сервере без всяких пхп, только с SSI/ESI?
Здравствуйте, Shtole, Вы писали:
S>Можно и на сервере. Только это требует сервера
S>Просто у HTML есть огромное число применений, когда никакой сервер в принципе не нужен. А шаблонизация нужна.
В таком случае достаточно взять любой шаблонизатор и 1 раз заранее скомпилировать, если сервер не нужен, динамика не нужна, то все будет так как ты хочешь
Ну, лет 25 назад можно было говорить про увеличение объема на диске при таком подходе, но сейчас это смешно.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, fk0, Вы писали:
S>>Какие были инженерные резоны против такого решения?
fk0> То, что документ не целостный получается? Да и смысл? Если можно собрать документ fk0>из кусочков в браузере, то почему бы не сделать это сразу? (заранее собрать C-препроцессором)
У меня есть два вопроса и два возражения.
Вопросы следующие. Почему вдруг именно C-препроцессором? В Юникс-культуре его использовали для сборки файлов? Мой вопрос во многом обусловлен тем, что я плохо знаю древний Юникс. Не застал-с.
Второй вопрос. Я, к своему стыду, не знаю, как можно пользоваться сишным препроцессором отдельно от компилятора. Для меня это монолит. Точно можно? А в наши дни? В VS2019, например. Или в gcc.
Теперь возражения. Допустим, у нас шаблон на 100К и мы его вставили в 10 файлов. Это уже мегабайт. Я понимаю, что в наши дни, когда «двести метров джаваскрипта грузят текста триста байт» это мало кого волнует, но всё-таки. Только опять вот этого не надо: сервер, gzip... У HTML миллион применений, не везде есть возможность всунуть компрессор.
Второе возражение тут уже кто-то выдвигал (в другом контексте). Кажется, это был Sinclair. Но чтобы не было глухого телефона, я сформулирую его от своего имени, как сам понимаю (т.е. все вопросы ко мне, пожалуйста). Любой конвеер в IT это плохо, это ОЧЕНЬ плохо. От них надо по возможности избавляться. Если у вас в одном случае надо сохранить файл и отдать его в препроцессор, а во втором — просто сохранить файл, второй случай и надо предпочесть. Конечно, если вы хотите простое и недорогое решение. Если лохов путать, то, конечно, конвеер надо делать подлиннее, а шаги позаковыристее.
fk0> Вот не понял мотивации вообще. Есть же SSI.
SSI это server-side. Многие уже, наверно, и не помнят, что MSDN когда-то был приложением.
S>>>Если говорить про то, что сейчас. Сейчас его развивают компании, основной актив которых — сервера. Был бы странно, если бы в него добавили что-то настолько «антисерверное».
R>>Это типа "у нас много серверов, давайте придумаем что-то, что их нагрузит не по-децки"... Так вряд ли кто-то думает. Сознательно создавать работу для своего оборудования никому не надо. Народ очень хорошо умеет деньги считать.
S>Лол. Так что ж они не сделают? Если сборка на клиенте действительно снизит нагрузку.
Каким образом #include снизит нагрузку? Я вижу дополнительный сетевой запрос, который сильно затормозит загрузку страницы. Приведи пример и объясни, за счет чего будет снижена нагрузка.
Здравствуйте, Reset, Вы писали:
S>>>>Если говорить про то, что сейчас. Сейчас его развивают компании, основной актив которых — сервера. Был бы странно, если бы в него добавили что-то настолько «антисерверное».
R>>>Это типа "у нас много серверов, давайте придумаем что-то, что их нагрузит не по-децки"... Так вряд ли кто-то думает. Сознательно создавать работу для своего оборудования никому не надо. Народ очень хорошо умеет деньги считать.
S>>Лол. Так что ж они не сделают? Если сборка на клиенте действительно снизит нагрузку.
R>Каким образом #include снизит нагрузку? Я вижу дополнительный сетевой запрос, который сильно затормозит загрузку страницы. Приведи пример и объясни, за счет чего будет снижена нагрузка.
Я написал очень простую вещь: сейчас HTML развивают компании, основной актив которых — сервера. (Имея в виду Гугл с его Хромом. Как сказал один умный человек, сегодня бери сиплюсплюсный код, из которого он состоит, описывай, вот тебе и будет спецификация HTML, а остальное, включая W3C, просто ширма, чтобы скрыть этот неприглядный факт). Было бы странно, если бы они его развивали в направлении, в котором сервера не нужны.
Причём тут нагрузка? Надо было сразу написать, что она к делу отношения не имеет, а не задавать вопросы, из которых это следует.
Здравствуйте, ути-пути, Вы писали:
УП>Здравствуйте, Shtole, Вы писали:
S>>Второй вопрос. Я, к своему стыду, не знаю, как можно пользоваться сишным препроцессором отдельно от компилятора.
УП>
Здравствуйте, Shtole, Вы писали:
S>Я написал очень простую вещь: сейчас HTML развивают компании, основной актив которых — сервера. (Имея в виду Гугл с его Хромом. Как сказал один умный человек, сегодня бери сиплюсплюсный код, из которого он состоит, описывай, вот тебе и будет спецификация HTML, а остальное, включая W3C, просто ширма, чтобы скрыть этот неприглядный факт). Было бы странно, если бы они его развивали в направлении, в котором сервера не нужны.
Если кто-то сомневается, что Гуглу нахрен не нужен бессерверный HTML, и он его убивает, пусть попробует быстренько открыть .htm-файл на Андроиде. Хоть в чём: хоть в webview, хоть в Chrome, хоть в Mobile Firefox. А потом поделится рецептом.
Андроид был первой на моей памяти операционной системой, выпущенной после 98-ого года, в которой без плясок с бубном это оказалось не сделать.
Здравствуйте, Shtole, Вы писали:
S>Какие были инженерные резоны против такого решения?
Мое имхо: Чистый HTML — это язык разметки для вывода на экран, реализующий его модуль мог не знать ничего про сетевые протоколы.
Это сейчас любой браузер такая банка с червями, а на начальных этапах удобнее было разделять функционал.
Более того, в те времена комп большую часть времени не имел выхода в интернет.
Или это могла быть пришедшая на локальный SMTP-сервак почта в формате HTML. Тогда даже первое обращение к документу происходило при уже выключенном интернете.
Здравствуйте, graniar, Вы писали:
G>Мое имхо: Чистый HTML — это язык разметки для вывода на экран, реализующий его модуль мог не знать ничего про сетевые протоколы.
включаемый файл может лежать рядом. Зачем сетевые протоколы?
Здравствуйте, CRT, Вы писали:
G>>Мое имхо: Чистый HTML — это язык разметки для вывода на экран, реализующий его модуль мог не знать ничего про сетевые протоколы. CRT>включаемый файл может лежать рядом. Зачем сетевые протоколы?
Рядом, это где? Если браузер запросил http://site.com/index.html, то он его и получил, и не узнает, какие еще файлы ему нужны, пока не распарсит.
По идее, сервер мог бы сразу отдавать пачку файлов, как в MIME-сообщении.
Ну вот так реализовано оно было прародителями веба, не все сразу продумали.
Здравствуйте, graniar, Вы писали:
S>>Какие были инженерные резоны против такого решения?
G>Мое имхо: Чистый HTML — это язык разметки для вывода на экран, реализующий его модуль мог не знать ничего про сетевые протоколы. G>Это сейчас любой браузер такая банка с червями, а на начальных этапах удобнее было разделять функционал. G>Более того, в те времена комп большую часть времени не имел выхода в интернет. G>Или это могла быть пришедшая на локальный SMTP-сервак почта в формате HTML. Тогда даже первое обращение к документу происходило при уже выключенном интернете.
А картинки?
Если картинки можно держать во внешних файлах, почему нельзя кусок HTML'я держать во внешнем файле?
Ты же в файле a.html можешь указать <img src="i.png">
и открыть этот файл a.html локально у себя на компьютере в браузере
и браузер без всяких сетевых протоколов попытается прочитать файл i.png с диска
из той же папки где лежит a.html
почему так же нельзя было сделать
<include src="b.html">
?
Картинки это опциональная штука, если не получается загрузить, показывается текст из alt.
S>Если картинки можно держать во внешних файлах, почему нельзя кусок HTML'я держать во внешнем файле?
C недогруженным #include может похериться структура документа.
Чтобы этого не происходило, придумали фреймы. Которые, если не получается загрузить, показывают пустой прямоугольник.
Здравствуйте, Shtole, Вы писали:
S>Какие были инженерные резоны против такого решения?
S>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
Тут проблема не столько в ответе, сколько в вопросе. Откуда у вас вообще эта идея про #include? Сишный #include — это такой убогий костыль, существующий исключительно из-за отсутствия более зрелой модульности в языке. Т.е. оно конечно работает и покрывает полтора сценария, но стратегически это тупик.
Здравствуйте, graniar, Вы писали:
G>Здравствуйте, CRT, Вы писали:
CRT>>почему так же нельзя было сделать CRT>><include src="b.html"> CRT>>?
G>Потому-что в случае недоступности b.html может похериться структура документа, например
но это уже дргая причина , а не незнание "модулем" сетевых протоколов о чем ты писал и на что я возражал
Здравствуйте, Shtole, Вы писали:
S>>>Какие были инженерные резоны против такого решения? fk0>> То, что документ не целостный получается? Да и смысл? Если можно собрать документ fk0>>из кусочков в браузере, то почему бы не сделать это сразу? (заранее собрать C-препроцессором) S>У меня есть два вопроса и два возражения.
S>Вопросы следующие. Почему вдруг именно C-препроцессором? В Юникс-культуре его использовали для сборки файлов? Мой вопрос во многом обусловлен тем, что я плохо знаю древний Юникс. Не застал-с.
Можно другим препроцессором, например -- m4. На котором были сделаны конфиги sendmail. Страшное зрелище надо сказать...
Но "#include" -- это ж директива C-препроцессора, потому и.
S>Второй вопрос. Я, к своему стыду, не знаю, как можно пользоваться сишным препроцессором отдельно от компилятора. Для меня это монолит. Точно можно? А в наши дни? В VS2019, например. Или в gcc.
Не только можно, но и нужно. C-препроцессор это по-сути отдельная совершенно программа и к компиляторам C/C++ отношения
можно сказать не имеет. И использовалась в совершенно разнообразных местах именно что для подстановок текста, условного
включения фрагментов текста, для #include. Например вспоминается imake и/или xmkmf -- система сборки для X11, где внутри
использовался C-препроцессор.
И кстати, я однажды делал сайт и собирал его тоже C-препроцессором (в один большой html, который неудобно так редактировать,
но удобно загружать в браузер в виде одной сущности).
S>Теперь возражения. Допустим, у нас шаблон на 100К и мы его вставили в 10 файлов. Это уже мегабайт. Я понимаю, что в наши дни, когда «двести метров джаваскрипта грузят текста триста байт» это мало кого волнует, но всё-таки. Только опять вот этого не надо: сервер, gzip... У HTML миллион применений, не везде есть возможность всунуть компрессор.
В этом смысле да, использование препроцессора расточительно и не нужно. Я выше о другом случае, когда весь сайт вообще
превращается ровно в одну html-страницу (грузится всё и сразу). На самом деле это не сайт, а веб-аппликация, так что
подход вполне оправдан.
И кроме того, gzip или даже более мощный специфический (для сжимаемых данных) компрессор отнюдь не плохая идея.
Декомпрессор можно сделать собственно на javascript. И загружать можно не целиком страницу каждый раз, а только диффы
(https://www.freebsd.org/cgi/man.cgi?query=bsdiff&sektion=1) между современной и имеющейся (из web storage) версиями.
Только боюсь это хайенд не уровня современных веб-дизайнеров, предложишь -- как на идиота посмотрят. Но сделать-то можно.
Просто у современных (моложе 40 лет) разработчиков зх-спектрума в детстве не было. Что такое 48 килобайт они не
представляют, и как в них (в игрушку) можно впихнуть полсотни экранов с цветной графикой.
S>Второе возражение тут уже кто-то выдвигал (в другом контексте). Кажется, это был Sinclair. Но чтобы не было глухого телефона, я сформулирую его от своего имени, как сам понимаю (т.е. все вопросы ко мне, пожалуйста). Любой конвеер в IT это плохо, это ОЧЕНЬ плохо. От них надо по возможности избавляться. Если у вас в одном случае надо сохранить файл и отдать его в препроцессор, а во втором — просто сохранить файл, второй случай и надо предпочесть. Конечно, если вы хотите простое и недорогое решение. Если лохов путать, то, конечно, конвеер надо делать подлиннее, а шаги позаковыристее.
Мотивации не вижу. Конвейер -- это подход "разделяй и влавствуй", он ведёт к снижению сложности системы в целом
путём её декомпозиции на относительно независимые элементы. Не считаю, что конвейер -- это плохо. Скорей монолит -- плохо.
Даром что ли все ломанулись в "микросервисы".
fk0>> Вот не понял мотивации вообще. Есть же SSI. S>SSI это server-side. Многие уже, наверно, и не помнят, что MSDN когда-то был приложением.
Понял о чём речь. Да, такого include нет, но его даже нельзя сделать через JS.
Оно было бы полезно безусловно, но с другой стороны работа исключительно с локальными файлами --
очень ограниченная область применения. В конце концов MSDN мог бы внутри себя иметь маленький
веб-сервер. Впрочем в те времена и XHR по-моему не было.
Здравствуйте, Shtole, Вы писали:
S>Какие были инженерные резоны против такого решения?
S>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, Shtole, Вы писали:
S>>Какие были инженерные резоны против такого решения?
S>>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
vaa>есть же и без пхп, js или паковщики vaa>https://css-tricks.com/the-simplest-ways-to-handle-html-includes/
Первое предложение оттуда:
It’s extremely surprising to me that HTML has never had any way to include other HTML files within it.
Вот и я... экстримли сюрпрайзед.
Дальше идёт:
<include src="./footer.html"></include>
That’s not real, by the way. I just wish it was.
Ну а дальше, как водится, набор воркэраундов.
Вопрос в том, почему не сделали так, как мы все это представляем. (Тут ниже приведён пример: <include src="b.html">, синтаксис такой же с точностью до закрывающего тега).
Здравствуйте, graniar, Вы писали:
CRT>>почему так же нельзя было сделать CRT>><include src="b.html"> CRT>>?
G>Потому-что в случае недоступности b.html может похериться структура документа, например
G>b.html:
G>blah-blah-blah
G></TD></TR></TABLE>
G>
G>На этот случай придумали фреймы, которые грузятся в заранее размеченные области.
Ну так, никто не мешает сразу в a.html написать:
G>a.html:
G>blah-blah-blah
G></TD></TR></TABLE>
G>
Как-то живут с этим. Браузеры даже умеют домысливать в определённых рамках, что хотел сказать автор.
Здравствуйте, rosencrantz, Вы писали:
S>>Какие были инженерные резоны против такого решения?
S>>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
R>Тут проблема не столько в ответе, сколько в вопросе. Откуда у вас вообще эта идея про #include? Сишный #include — это такой убогий костыль, существующий исключительно из-за отсутствия более зрелой модульности в языке. Т.е. оно конечно работает и покрывает полтора сценария, но стратегически это тупик.
А откуда у автора такая идея? Почему он удивлён отсутствием? Я к тому, что если этот вопрос приходит в голову многим, значит, это объективная потребность.
S>Вопрос в том, почему не сделали так, как мы все это представляем. (Тут ниже приведён пример: <include src="b.html">, синтаксис такой же с точностью до закрывающего тега).
Как минимум проблема с секьюрити для локальных файлов. Ты запросил открыть один файл, а оно другой открыло,
который ты может не хочешь, чтоб скрипты со страницы читали. Более того, ведь <include> с _любым_ именем вообще
может сформироваться скриптом. И будет потом, условно, <include "~/.bitcon/wallet.dat">.
Здравствуйте, fk0, Вы писали:
fk0> Как минимум проблема с секьюрити для локальных файлов. Ты запросил открыть один файл, а оно другой открыло, fk0>который ты может не хочешь, чтоб скрипты со страницы читали. Более того, ведь <include> с _любым_ именем вообще fk0>может сформироваться скриптом. И будет потом, условно, <include "~/.bitcon/wallet.dat">.
Когда HTML только появлялся, там же не было ни Аякса, ничего. Откуда проблемы с секьюрности бы взялись?
В наши дни это легко можно решить, например, требованием указывать в начале шаблона, что это шаблон. Хотя бы в виде <![CDATA[template]]>.
Здравствуйте, Shtole, Вы писали:
S>Вопрос в том, почему не сделали так, как мы все это представляем. (Тут ниже приведён пример: <include src="b.html">, синтаксис такой же с точностью до закрывающего тега).
потому что суть протокола не во внедрении документов, а в связывании.
<a href="b.html">b</a>
Гипертекст т.е. именно избежать одного большого документа при передаче информации.
Иначе возникла бы дурная бесконечность.
Здравствуйте, Shtole, Вы писали:
S>Какие были инженерные резоны против такого решения?
Идемпотентность. Никто не хочет иметь документ, который в любой момент может измениться или сломаться. А что если includ-ить fifo-файл? А если файл на сетевом диске? А если ресурс вообще не файл? Что делать с кэшированием? 100500 вопросов и все без ответа.
S>изрядная доля сайтов на PHP могла бы быть переведена на голый HTML
PHP без сервера не существует, а с сервером есть SSI.
Здравствуйте, cppguard, Вы писали:
>100500 вопросов и все без ответа.
Я бы не сказал, что вопросы какие-то заковыристые.
C>Идемпотентность. Никто не хочет иметь документ, который в любой момент может измениться или сломаться. А что если includ-ить fifo-файл?
Для начала, что такое fifo-файл? Я знаю, что такое FIFO, и знаю, что такое файл, но вместе не складывается.
>А если файл на сетевом диске?
А если сеть пропала в процессе передачи единственного файла? Чем это будет отличаться?
>А если ресурс вообще не файл?
И что? А если исходный ресурс вообще не файл?
>Что делать с кэшированием?
То же, что и в остальных случаях. Ну, может, ввести дополнительное правило, что устаревание связанных файлов наследуется.
S>>изрядная доля сайтов на PHP могла бы быть переведена на голый HTML
C>PHP без сервера не существует, а с сервером есть SSI.
Просто очень многие на моей памяти юзали PHP главным образом как шаблонизатор.
Здравствуйте, Shtole, Вы писали:
S>Какие были инженерные резоны против такого решения?
Я думаю инженерных резонов не было. HTML — это разметка документа, а не его компоновка.
Т.е. казалось бы, что IMG — это такой include для картинок, но на самом деле нет. IMG — это вынужденная мера связанная с тем, что картинки хранятся в отдельных файлах и с тем, что не все дисплеи умели графику отображать.
И не забывайте, что IMG не отображались сразу, а по запросу пользователя.
Здравствуйте, Reset, Вы писали:
S>>>>Если говорить про то, что сейчас. Сейчас его развивают компании, основной актив которых — сервера. Был бы странно, если бы в него добавили что-то настолько «антисерверное».
R>>>Это типа "у нас много серверов, давайте придумаем что-то, что их нагрузит не по-децки"... Так вряд ли кто-то думает. Сознательно создавать работу для своего оборудования никому не надо. Народ очень хорошо умеет деньги считать.
S>>Лол. Так что ж они не сделают? Если сборка на клиенте действительно снизит нагрузку.
R>Каким образом #include снизит нагрузку? Я вижу дополнительный сетевой запрос, который сильно затормозит загрузку страницы. Приведи пример и объясни, за счет чего будет снижена нагрузка.
Здравствуйте, fk0, Вы писали:
fk0> Как минимум проблема с секьюрити для локальных файлов. Ты запросил открыть один файл, а оно другой открыло, fk0>который ты может не хочешь, чтоб скрипты со страницы читали. Более того, ведь <include> с _любым_ именем вообще fk0>может сформироваться скриптом. И будет потом, условно, <include "~/.bitcon/wallet.dat">.
Ровно те же вопросы можно задать про теги img, script, link, может ещё какие.
Здравствуйте, Shtole, Вы писали:
S>Просто очень многие на моей памяти юзали PHP главным образом как шаблонизатор.
В эпоху web 1.0 сайты делали все, кому не лень, поэтому и качество решений соответствующее было. Я в студенческие годы делал каталог для производителя мебели, там SSI пришёлся очень кстати, PHP был бы перебором. Вообще за всё время работы программистом я заметил, что тенденция "использую только то, что нашёл, нового не пробую" это почти как зотолой стандарт в индустрии. И что характерно — следуют ему все, от мала до велика. Facebook был написан на PHP, и потом для него героически писали транслятор в С++, и возже — виртуальную машину. Vk повторили этот "подвиг" с их KPHP. И всем пофиг, что переписать всё это дело нормально стоило бы дешевле.
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, Shtole, Вы писали:
S>>Какие были инженерные резоны против такого решения?
BFE>Я думаю инженерных резонов не было. HTML — это разметка документа, а не его компоновка.
BFE>Т.е. казалось бы, что IMG — это такой include для картинок, но на самом деле нет. IMG — это вынужденная мера связанная с тем, что картинки хранятся в отдельных файлах и с тем, что не все дисплеи умели графику отображать.
Не совсем понимаю мысль. Вот сейчас можно делать картинки инлайновыми. Но ведь делают же их такими только изредка. Потому, что неудобно. Это культура поменялась, или что? В смысле, почему сейчас это добровольная мера, а раньше была вынужденная?
BFE>И не забывайте, что IMG не отображались сразу, а по запросу пользователя.
Здравствуйте, cppguard, Вы писали:
S>>Просто очень многие на моей памяти юзали PHP главным образом как шаблонизатор.
C>В эпоху web 1.0 сайты делали все, кому не лень, поэтому и качество решений соответствующее было. Я в студенческие годы делал каталог для производителя мебели, там SSI пришёлся очень кстати, PHP был бы перебором. Вообще за всё время работы программистом я заметил, что тенденция "использую только то, что нашёл, нового не пробую" это почти как зотолой стандарт в индустрии. И что характерно — следуют ему все, от мала до велика. Facebook был написан на PHP, и потом для него героически писали транслятор в С++, и возже — виртуальную машину. Vk повторили этот "подвиг" с их KPHP. И всем пофиг, что переписать всё это дело нормально стоило бы дешевле.
Да тут, скорее, не синдром гусёнка, тут немного иное. Если дают готовый комбайн бесплатно — зачем брать отдельно отвёртку и молоток? Есть люди, которые так делают, в английском языке их называют anal person (без негатива) — отголоски фрейдизма. PHP стартовал с SSI примерно одновременно (а именно: РАНО, считаем такую точность достаточной), умел много и стоял везде, зачем было морочиться с SSI, который больше ничего не умел? Вот его и использовали, причём некоторые — только для подстановки. А <include> на стороне клиента поменял бы правила — он не требует сервера.
Ещё немного про комбайны. С момента появления Trident (ocx от IE), я его активно юзал для... да, практически, всего. Например, чтобы тултипы с разметкой делать. Тоже люди большие глаза делали: тащить этого монстра для маленьких утилит... А почему нет? Винда так устроена, что оверхед в этом случае очень небольшой.
Здравствуйте, Shtole, Вы писали:
S>>>Какие были инженерные резоны против такого решения? BFE>>Я думаю инженерных резонов не было. HTML — это разметка документа, а не его компоновка. BFE>>Т.е. казалось бы, что IMG — это такой include для картинок, но на самом деле нет. IMG — это вынужденная мера связанная с тем, что картинки хранятся в отдельных файлах и с тем, что не все дисплеи умели графику отображать. S>Не совсем понимаю мысль. Вот сейчас можно делать картинки инлайновыми. Но ведь делают же их такими только изредка. Потому, что неудобно. Это культура поменялась, или что? В смысле, почему сейчас это добровольная мера, а раньше была вынужденная?
Ну не хранили раньше документы и картинки в одном файле — места было мало, поэтому хранить картинку в виде BASE64, скажем, не выгодно, а делать смесь из бинарных и текстовых данных в файле тоже не любили. Вообще HTML "вырос" из разметки документов и научных статей в которые добавили гиперссылки. В рамках этой логики документ разбивался на страницы и когда мы заходим на сайт — мы заходим на страницу, что в современных реалиях звучит странно. А изначально предполагалось, что у нас есть документ и мы можем его просматривать по страницам, для чего предусмотрены специальные теги <LINK>... Не думаю, что были какие-то резоны против include, наоборот, не было никаких резонов за include — информацию для заголовков (и футеров) предполагалось передавать в <HEAD> страницы.
При изучении любого "нового" инструмента у программиста есть стадия, когда "всё понятно, но вот <и тут некая проблема/вопрос>". Все через это проходят, это нормально.
Некоторые достаточно упорные программисты таки находят именно то решение, которое искали — "как сделать include? вот так". На этом для них вопрос закрывается. Но он конечно очень скоро будет открыт снова — в немного другой вариации (им в этот раз надо будет не include, а include с параметрами например)
Некоторые идут немного в другую сторону и находят, что есть целый удивительный мир шаблонизаторов и генераторов статических сайтов, которые решают не специфическую проблему "как сделать include", но предлагают целую стратегию — как нам применить композицию, чтобы собрать сайт по кусочкам.
S>А откуда у автора такая идея? Почему он удивлён отсутствием?
Автор работает на публику. Есть толпы джуниоров, про которых известно, что они будут гуглить этот вопрос. Под них написана статья.
S>Я к тому, что если этот вопрос приходит в голову многим, значит, это объективная потребность.
Гыгы. Ещё одна объективная потребность — чтобы программа работала и не падала с исключениями. Можно написать прекрасную статью про try-catch с пустым блоком catch — ведь это действительно решает проблему, правда? А книжки про обработку исключений, про тестирование — это для лохов.
Здравствуйте, Shtole, Вы писали:
S>Какие были инженерные резоны против такого решения?
В принципе, никаких. НО(!) когда "изобретали" HTML, его основное предназначение было "обмен научной документацией" (с попутными ссылками на другие документы). Т.е. даже наличие Интернета не было необходимостью! Тебе просто давали HTML-ку и ты её читал. Соотв. ни о каком "динамическом процессинге" тогда вообще речи не шло. Никто даже не представлял, что львиную долю интернета будет составлять WWW и гипертекст станет доминирующим форматом.
Здравствуйте, rosencrantz, Вы писали:
R>Некоторые идут немного в другую сторону и находят, что есть целый удивительный мир шаблонизаторов и генераторов статических сайтов, которые решают не специфическую проблему "как сделать include", но предлагают целую стратегию — как нам применить композицию, чтобы собрать сайт по кусочкам.
Ну, кто-то открывает для себя «удивительный мир шаблонизаторов», а кто-то его уже закрыл. Дело в том, что сейчас заставить работать вот такую разметку в Bootstrap-стиле:
...можно написав семь строчек джаваскрипта (считая фигурные скобки и записывая каждый шаг в переменную на отдельной строке). Вообще, тренд, я бы сказал, давно такой: отказываться от навесных инструментов (предыдущий тренд на создание которых привёл к появлению алколгольной игры «*.JS»). Хотя иногда с водой выплёскивают и ребёнка, и я не понимаю упоротых фанатов querySelectorAll().
Так вот, не смотря на всё на это, для некоторых целей я бы даже сейчас предпочёл любому шаблонизатору (от готового до самописного) простой include. Это просто разные измерения.
Про генератор статических сайтов я уже написал в другом месте. Любой конвеер без которого можно обойтись — просто профессиональный способ сохранить рабочее место или доходы. Как отвёртка PentalobeTM. Но какой дурак будет домой покупать шурупы с таким шлицем? Вот и простое сохранение файла предпочтительнее, чем сложный набор действий, если, конечно, цель не в том, чтобы развести на деньги.
S>>А откуда у автора такая идея? Почему он удивлён отсутствием?
R>Автор работает на публику. Есть толпы джуниоров, про которых известно, что они будут гуглить этот вопрос. Под них написана статья.
А у джуниоров этот вопрос для гугления откуда? Для меня тот факт, что автор задаётся вопросом на публике, признак того, что вопрос точно объективно существует, а не наоборот.
S>>Я к тому, что если этот вопрос приходит в голову многим, значит, это объективная потребность.
R>Гыгы. Ещё одна объективная потребность — чтобы программа работала и не падала с исключениями. Можно написать прекрасную статью про try-catch с пустым блоком catch — ведь это действительно решает проблему, правда? А книжки про обработку исключений, про тестирование — это для лохов.
Я НЕ принимаю этого сравнения. Вот рядом есть, как я теперь знаю, команда cpp, и она работает. В отличие от мифической программы, которая всегда работает и не падает с исключениями.
Здравствуйте, Baiker, Вы писали:
S>>Какие были инженерные резоны против такого решения?
B>В принципе, никаких. НО(!) когда "изобретали" HTML, его основное предназначение было "обмен научной документацией" (с попутными ссылками на другие документы). Т.е. даже наличие Интернета не было необходимостью! Тебе просто давали HTML-ку и ты её читал. Соотв. ни о каком "динамическом процессинге" тогда вообще речи не шло.
Я не понимаю, как из первого следует второе. По-моему, чисто локальные HTML-файлы, наоборот, сильнее дружат с инклюдами. Потому, что и то, и другое — файлоцентричные решения.
Здравствуйте, rosencrantz, Вы писали:
S>>Ну, кто-то открывает для себя «удивительный мир шаблонизаторов», а кто-то его уже закрыл.
R>Типа у вас седая борода и вы уже закрыли?
Я же привёл пример, как сейчас можно шаблонизироваться. Мне эти семь строчек скриптов сюда скопировать? Это, скорее, люди с седыми Мусташами до сих пор на шаблонизаторах сидят.
Здравствуйте, Shtole, Вы писали:
S>Здравствуйте, rosencrantz, Вы писали:
S>>>Ну, кто-то открывает для себя «удивительный мир шаблонизаторов», а кто-то его уже закрыл.
R>>Типа у вас седая борода и вы уже закрыли?
S>Я же привёл пример, как сейчас можно шаблонизироваться. Мне эти семь строчек скриптов сюда скопировать? Это, скорее, люди с седыми Мусташами до сих пор на шаблонизаторах сидят.
Ды можно и не копировать, я примерно представляю что можно написать в 7 строчек Я вам написал уже про разницу между "хочу инклюд" и "хочу декомпозицию", про стратегию, про возможность сделать шаг влево-вправо не изобретая велосипед за 2 часа до дедлайна, и т.д. — я понял уже, что вам на этом уровне вести дискуссию не интересно.
Здравствуйте, rosencrantz, Вы писали:
S>>>>Ну, кто-то открывает для себя «удивительный мир шаблонизаторов», а кто-то его уже закрыл.
R>>>Типа у вас седая борода и вы уже закрыли?
S>>Я же привёл пример, как сейчас можно шаблонизироваться. Мне эти семь строчек скриптов сюда скопировать? Это, скорее, люди с седыми Мусташами до сих пор на шаблонизаторах сидят.
R>Ды можно и не копировать, я примерно представляю что можно написать в 7 строчек Я вам написал уже про разницу между "хочу инклюд" и "хочу декомпозицию", про стратегию, про возможность сделать шаг влево-вправо не изобретая велосипед за 2 часа до дедлайна, и т.д. — я понял уже, что вам на этом уровне вести дискуссию не интересно.
Что плохого в том, чтобы опуститься на уровень, где приводятся примеры? Ну да, мне не очень интересно (скорее даже, непонятно) обсуждать голые абстракции.
Вот почему бы весь <template> не выносить в отдельный файл? На этом примере я пытаюсь показать, что шаблонизаторы и инклюды — просто перпендикулярные идеи. А раз так, я не понимаю, что должно произойти с человеком при открытии «удивительного мира шаблонизаторов», чтобы он забыл после этого про инклуды.
