1) Если бы представляли, не писали бы глупых высказываний, по поводу того, что есть файл.
2) Я не сказал, что он не годится. Он работает. Но можно сделать иначе, что будет намного лучше. Причины этого я уже описал выше несколько раз.
3) По поводу get_headers, думал уже забыли, так как все что касается его я так же сказал выше.
4) Швейцарский нож.. Дело вот в чем (провожу аналогию дальше) file_get_contents это в данном случае на штопор, а нож (я уже говорил, о том что эта функция не предназначена для таких задач ?). Ножом тоже можно открыть бутылку, но это будет не корректно. А вот CURl это швейцарский нож, в котором штопор имеется. Так что либо предлагайте какой-то штопор без лишнего функционала, либо пользуйтесь швейцарским ножом. Но никак не стоит советовать отковыривать пробку - простым ножиком )
Андрей: если бы вы знали хотябы чуть чуть о том как работает http, веб сервера и в частности, каким образом на все это влияет fast_cgi вы бы так же были в курсе о том, что все, что отдает веб сервер зовется файлом (документом, ресурсом), просто одни файлы являются статическими а другие генерируются каким-то программным кодом.
is_file совсем не то, о чем идет речь в разговоре, а file_exists насколько я помню не может проверить существование файла на удаленном сервере, по крайней мере не может отправить заголовки, которые необходимы при http аутентификации.
По поводу file_get_contents, я снова говорю о том, что у этого метода есть недостатки, в частности - использование собачки и плохое самодокументирование кода(этот метод читает файл, а не проверяет его на существование), что является не самым последним пунктом в списке показателей качественного кода.
Если curl - швейцарский нож - это не значит, что его нельзя использовать. И не говорите мне, что когда у вас в кормане лежит вот такой вот предмет и вам нужно открыть шампанское вы побежите за штопором, а многофункциональный ножик будете использовать лишь в том случае, когда под шампанское вы собираетесь намазать пару бутердбродов со шпротами, открутить несколько болтов и попутно спилить пару веток которые, к удивлению у вас так же имеются...
Андрей: иной раз удивляюсь, как же люди любят подменять факты и загонять человека в угол) Сначала вы спросили, как проверить файл на существование, а потом, сразу, как прочитать его) Вот я и растерялся)
Ко второй части. Заметьте, сначала нужно проверить файл на существование :)
file get contents с этой задачей конечно справляется, но не так очевидно как curl и имеет некоторый недостаток о котором я писал выше с:
Андрей: а вот после того, как сервер вернул 200 и 304 ответ, можно достать страничку используя curl) Мне сейчас на столько лень, что я бы выразил свою мысль так же кратко как это сделал DevMan :)
Андрей: Из вышеописаного листинга тс может показаться, что использовать оператор управления ошибками это стандарт де факто, однако это моветон.
file_get_contents выкидывает ошибку уровня E_WARNING, что позволяет без проблем обработать ее, а не просто скушать и "забить" как это делает оператор собачка.
Андрей Инишев: а я и не говорил, что с первым фреймворком не придется мучаться. Я говорил о том, что с первым фреймворком придется помучаться побольше чем с остальными, и не надо просто брать и фигачить с:
Так же я не говорил о том, что после прочтения доков все должно разложиться по полочкам в голове. Я говорил лишь о том, что сначала необходимо узнать на что способен тот инструмент с которым тебе предстоит работать.
В этом плане мне импонирует Symfony, в котором сначала можно поработать с модулями фреймворка не углубляясь в рабочий процесс с самой его архитектурой.
Андрей Инишев: пора добавлять вот такие ответы в список вредных советов)
Брать и "фигачить" на фреймворке неподготовленному человеку, это все равно, что дать ему бензопилу, вместо ножа... и знаете как он будет резать хлеб?) Водить туда сюда по злосчастной буханке.. и знаете когда он успокоится ?) Когда перережет весь хлеб в своей стране (почему во всей стране а не только у себя в кухне, будет понятно в самом конце).
Другими словами:
Не зная фреймворка он будет использовать не весь его функционал, сначала лучше понять основной воркфлоу при работе с такими инструментами, потом досконально прочитать документацию и узнать возможности фреймворка. Фор экзампл, у меня есть знакомый, который после того как "выучил" Laravel использовал от него только MVC каркас, конфиги, маршрутаризацию и конечно начальные понятия о action records у него были, а вот все relationships в бд, работу с сессиями, куками, файлами, очередями (да, он уже использовал очереди) реализовывал сам, не зная, что этот и еще много другого функционала реализовано и коробки.
Следствие:
Я - заказчик, тс - первый исполнитель, ты - исправляешь косяки за ним. Я обещал что проект был построен на Yii2, так как тс у нас от таких советов слишком быстро "выучил" фреймворк, ты берешься за голову и вместо того чтобы исправлять косяки за тс, сидишь и переписываешь всю рутинную работу с модулями на лад Yii2.
Вот собственно почему (возвращаюсь к вопросу о буханках и бензопилах) вот такие советы влияют не только на дилетантов в этом деле но и на всех разработчиков.
666Wolf666: неужели так сложно найти добросовестных заказчиков и делать качественный продукт вместе? Как по мне, если у разработчика в портфеле работы с вот такими "капканами" чести ему это много не прибавляет.