Здравствуйте, 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 — ведь это действительно решает проблему, правда? А книжки про обработку исключений, про тестирование — это для лохов.
