об = оутпут буфер. старт = старт. запускаем буфер на выходном потоке. все данные относящиеся к потоку будут заруливать в буфер до тех пор пока мы с ним что-то не сделаем. суть в том что если код написан криво и нелогично то где-то в конце логики невозможно будет установить заголовок так как данные уже отправлены а заголовки отправляются перед данными. когда мы заворачивает данные в буфер то мы можем продолжать работать с заголовками - они не отправятся до тех пор пока мы не запишем что-либо в поток вне буфера (или не закроем буфер).
обстарт в самом начале, потом пишешь эхо сколько хочешь в любом месте, куки ставишь, сессии и прочая и прочая. в конце - echo ob_get_clean()
Вопрос, делаю одну точку входа на сайт Код (Text): switch ($_GET['c']) { case 'edit': $controller = new Edit(); break; default: $controller = new Articles(); } $controller->Request(); Если я не передаю в гет переменную С, то пишет Undefined index: c in C:\VertrigoServ\www\art\index.php on line 9, вопрос почему? Вроде же по логике так, если нет переменной, то грузим default .Причём контроллер Articles работает, и всё отображается, просто поверх всего выскакивает данная ошибка.
да все нормально. ячейка такая не определена но используется. отсюда выпадает предупреждение. а поскольку оно не определено то вполне удовлетворяет ветке default вашего свича. можно сделать костыль типа $c = isset( $_GET['c'] ) ? $_GET['c'] : null; switch( $c ). в таком случае если не будет такого индекса то переменная ц получит "дефолтное" значение (налл) и так же удачно будет вызывать дефолтную ветку свича но без ностиса на тему использования несуществующей переменной
это потому что в этих уроках предлагается выключить мозг и вывод предупреждений. никто не спорит что на продакшене не должно быть вывода ошибок в явном виде - нужно писать свои обработчики. но подавлять появление ошибок нельзя. вот ваша книга подавляет ошибки хотя на самом деле переменная не определена и на 99% хостингов это будет порождать запись в журнале ошибок. нахер это надо?
"нахер это надо?" Добавлено спустя 6 минут 3 секунды: + ещё общий вопрос. Как думаете, лучше переходить на msqli или остаться на mysql ?
на импрувд надо было еще лет пять назад переходить. так что тут даже не обсуждается. тем более не за горами момент когда устаревшее расширение просто будет удалено и все сценарии его использующие следовательно перестанут работать.
Ну перехожу на mysqli, встал вот такой вопрос. В каких случаях лучше использовать подготавлеваемый запрос? И при передаче значений, он сам вроде проверяет на sql-инъекции ?
Лучше на PDO сразу перейти.Это более свежая библ. и не сложнее mysqli,я её сразу перескочил ,после mysql. Плюс PDO работает быстрее и надежнее защищена от инъекций. Код (Text): $stmt = $db ->prepare( "INSERT INTO users (firstname, lastname, email) value (:firstname, :lastname, :email)" ); $stmt ->bindParam( ':firstname' , $firstname ); $stmt ->bindParam( ':lastname' , $lastname ); $stmt ->bindParam( ':email' , $email ); $firstname = "John" ; $lastname = "Smith" ; $email = "john@test.com" ; $stmt ->execute();
со вторым не поспорю. плюсом добавлю и бОльшее кол-во СУБД. а вот по первому - перфоманс-тест с обоснованием будет?
не думал что в такой чудесный день кому-то придется расшифровывать его же мысли. второе выделено зеленым и к нему я не придираюсь. даже более того, я добавляю что еще одним плюсом ПДО - поддержка большого кол-ва СУБД. а вот по первому - выделено красным - возникает желание получить доказательства данного утверждения. какие тесты проводились перед тем как бросаться 100% заявлениями что пдо быстрее импрувда? результаты этих тестов и ожидаются в качестве обоснования утверждения. заранее спасибо))
я как дурачек тебе в личку строчу и можно заставлять меня ждать по три дня как девочку, хотя на форуме ты бываешь =) ага
а я когда машину в белый перекрасил расход топлива визуально уменьшился. короче понятно, обоснования не будет.
Не не, PDO конечно хорош, есть свои + и весьма весомые. Но есть и минусы, на счёт скорости не знаю, но PDO подразумевает определённую абстракцию при работе с базой. В конечном счёте, если ваш проект разрастается, вы все-равно перейдёте на mysqli.