Метафизика вопроса

Вид материала

Документы

Содержание Откуда что взялось Назначение и возможности Установка и проверка Модули расширения Где взять дополнительную информацию 2. Синтаксис языка 2.3. Вывод информации Vasya is 23 years old. Сегодня пятница Array( [a] => apple [b] => banana [c] => Array( [0] => x [1] => y [2] => z) ) 2.8. Область видимости переменных. Hello world 2.12. Выражения и приоритет операций Практические задания 3. Классы. объекты. отличия php 5. 3.2. Описание класса 3.3. Использование классов 3.5. Конструкторы и деструкторы Запущен конструктор 3.6. Область видимости ... Полное содержание

Подобный материал:

• Тема:  Метафизика Аристотеля, 57.7kb.
• С. Л. Как возможна метафизика? Специфика метафизического дискурса, 253.49kb.
• Рене Генон – Восточная метафизика, 258.18kb.
• Д. В. Михель Метафизика в поисках своих оснований, 2733.42kb.
• Л. Я. Аверьянов почему люди задают вопросы?, 2321.77kb.
• Тема заседания, 589.89kb.
• Протокол пленарного заседания Международного форума «Мегаполис: XXI век» с обсуждением, 722.08kb.
• «Бытие как смысл существования», 331.62kb.
• Равернутый план занятия № п/п Учебные вопросы Время в мин. Содержание учебного вопроса,, 137.79kb.
• Методические рекомендации для срс тема: Психотропные средства стимулирующего типа действия., 210.2kb.

1. ВВЕДЕНИЕ В PHP

1. Метафизика вопроса
   

Итак, грамотно верстать странички, размещать и грамотно форматировать информацию на них, и делать к ним гибко модифицируемое оформление, вы уже умеете. Тем не менее, что называется, глядя в интернет, можно заметить, что статических страниц там хоть и много, но самое интересное из представленного, явно навевает мысль, что вряд ли эти все эти вещи хранятся в виде статических html-страничек.

Если задуматься над тем, как это сделано, то сразу становится понятно, что каким-то образом эти страницы, полностью или частично, должны генерироваться динамически. Причём, вряд ли это делается на клиентской стороне – просто по логике, большая часть этих процессов генерации просто обязаны происходить на веб-сервере.

Если начать логически рассуждать дальше, то также можно сделать предположение, что вряд ли этой генерацией обычно занимается некое универсальное средство - должна быть какая-то специализированная технология, оптимизированная именно под генерацию динамических html-страниц web-сервером.

На деле, конечно, окажется, что использование универсальных средств для вот такой динамической генерации html-страниц в контексте web-сервера тоже имеет место, и во многих случаях даже является оправданным. А, кроме того, специальных технологий, предназначенных для этой цели, тоже существует несколько. Тем не менее, средством, вполне заслуженно получившим наибольшее распространение, однозначно является PHP. Именно его изучением мы и займёмся в рамках данного учебного курса.

Немного о терминологии. Часто можно услышать в разговоре такое сочетание, как «PHP-скрипт». Как его понимать, и отличается ли «PHP-скрипт» от «программы на PHP»? Ответ: однозначное нет. PHP до сих пор является исключительно интерпретируемым языком, то есть в момент работы программы обрабатывается непосредственно файл, содержащий исходный код (исключения возможны, но о них отдельно и гораздо позже). То есть, всякая программа, написанная на PHP, является интерпретируемой, то есть, в принципе, может быть названа «скриптом».

2. Откуда что взялось
   

Что же такое это самое «пи-эйч-пи», а то и просто «пэ-хп-пэ», о котором мы собираемся разговаривать? Что умеет, и откуда взялось? Вначале – немного об истории.

Официальная версия гласит, что PHP, как язык программирования, был создан программистом Расмусом Лердорфом с целью сделать его домашнюю страничку в Интернете более интерактивной, более привлекательной для посетителей, а также, как формулируют некоторые источники, «чтобы иметь представление о тех людях, которые посещают его сайт и знакомятся с его резюме». Осенью 1994 года господин Лердорф разработал базовый синтаксис и создал первый интерпретатор своего языка, дав и языку, и программе, его интерпретировавшей, название Personal Home Page Tools - т. е. РНР. В той самой ранней версии, интерпретатор мог обрабатывать лишь несколько основных команд, однако начало было положено.

Примечательно, что интерпретатор сам был написан на интерпретируемом языке Perl, предназначенном, в общем, для тех же целей. Мотивацией для написания было крайнее неудобство синтаксиса Perl – те, кто знаком с языком Perl будут иметь возможность оценить, что данная разработка, несомненно, имела смысл.

В следующем, 1995 году господин Лердорф доработал интерпретатор, объединив его со своей же программой Form Interpretator, позволявшей обрабатывать html-формы. Кроме того, сама программа была переписана на языке C, и, хотя сама по себе осталась интерпретатором, позволила производить выполнение программ гораздо быстрее. Также, это позволило встраивать интерпретатор PHP непосредственно в web-сервер Apache.

По утверждениям самого автора, неожиданно для него самого, пользователи сервера, где располагался сайт с первой версией PНР, попросили себе такой же инструмент, и он довольно быстро перерос в самостоятельный проект. Именно от варианта 1995 года пошёл отсчёт версий нынешнего PHP.

В том же 1995 году функциональность интерпретатора была дополнена ключевыми, с нашей точки зрения, возможностями взаимодействия с серверными базами данных, а также работы с графическими изображениями. Благодаря этому, например, появилась возможность автоматически создавать gif-файлы с кнопками-счётчиками посещений, и тому подобные приятные вещи. Вторая версия, содержавшая уже вот такие, расширенные, возможности, вышла к конце всё того же 1995 года.

К концу 1997 года РНР использовался более чем на пятидесяти тысячах сайтов.
Web-мастера быстро оценили достоинства нового языка web-программирования, такие как легкость освоения и богатство возможностей, и вскоре использовавшиеся до него традиционные Perl и С стали сдавать свои позиции.

Так как исходный код интерпретатора был открытым, а сам интерпретатор бесплатным, то энтузиасты стали заниматься его доработкой, и летом 1998 года появился на свет РНРЗ - детище Зеева Сураски и Энди Гутманса. РНР 3 был переписан "с нуля", так как его авторы сочли код предыдущих версий недостаточно эффективным. Кроме того, РНР З стал весьма легко расширяемым продуктом. Любой, создавший на основе определенных стандартов модуль расширения РНР, мог конечными усилиями этот модуль интегрировать с программными файлами РНР.

Уже к концу 1999 года число сайтов, построенных на основе РНР, перевалило за миллион. Весьма важным достоинством данного средства также явилось то, что программы интерпретации команд РНР, были созданы практически для всех операционных систем, от Windows до Unix и Linux. Таким образом, PHP стал кроссплатформенным средством, хотя ещё не так давно считалось, что PHP работает в связке только с сервером Apache, и, как правило, лишь под платформами семейства Unix.

Используемая в основном до сих пор четвёртая версия интерпретатора PHP была создана в 2000 году компанией Zend Technologies (по сути, это был проект тех же самых людей, что и PHP 3, только они к тому времени уже были не талантливыми программистами, а руководителями основанной ими фирмы). РНР 4 был дополнен множеством новых функций, но, несмотря на то, что стал разрабатываться фирмой, остался бесплатным и свободнораспространяемым продуктом.

В 2004 году была выпущена пятая версия PHP. Несмотря на огромное количество дополнений, связанных как со структурами языка (например, расширением возможностей объектно-ориентированного программирования), так и общей оптимизацией работы интерпретатора, за прошедшие 2 года PHP 5 не смог вытеснить четвёртую версию.

Поскольку, в плане синтаксиса, основные отличия лежат в области классов и объектов, большая часть того, что мы будем рассматривать, с одинаковым успехом относится к обеим версиям. Там, где между двумя актуальными ныне версиями есть разница, мы будем это особо оговаривать.

Кстати, как это часто бывает с программами, которые изначально не являются коммерческим продуктом, где-то по ходу развития оказалось, что уже PHP расшифровывается, как «PHP: Hypertext Preprocessor». Что говорит, в первую очередь, о том, что желающие как-либо расшифровать PHP по определению занимаются ерундой. PHP – он и есть PHP, замечательная вещь, и расшифровывать его незачем.

В завершение разговора об истории развития продукта следует сказать, что не так давно фирма Zend объявила, что ведёт разработку коммерческой версии PHP, которая будет компилируемой, а не интерпретируемой. Данная перспектива выглядит весьма заманчивой, с тех точек зрения, что, во-первых, это позволит сильно повысить эффективность выполнения сервером программ на PHP, и, во-вторых, позволит разработчикам создавать и устанавливать заказчикам свои системы, разработанные на PHP, не предоставляя им исходных кодов. Главное, чтобы параллельно с этим, сохранилась и бесплатная интерпретируемая ветвь продукта.

3. Назначение и возможности
   

Теперь расскажем немного более детально о назначении и возможностях.

В общем, РНР способен делать все, что делают другие CGI программы. Тут необходимо оговориться: нельзя однозначно сказать, что PHP является CGI-программой, поскольку это зависит от того, как он установлен на web-сервере. То есть, действуя абсолютно аналогичным, с точки зрения пользователя сайта, образом, PHP может быть как CGI-программой, так и модулем расширения web-сервера. Чуть дальше мы вернёмся к рассмотрению этих вопросов.

Для понимания назначения и возможностей PHP, нам необходимо рассмотреть, что же происходит, когда интернет-браузер пользователя запрашивает у web-сервера «а подай-ка мне (по протоколу http, естественно) файл вот такой-то .php». А происходит следующее: web-сервер, получив запрос, находит у себя требуемый файл, по расширению (которое обязательно прописывается в его, web-сервера, конфигурациях) распознаёт, что указанный файл, перед отправкой запросившему, должен быть обработан модулем PHP. Из этой логики, кстати, следует определение PHP, как препроцессора для текстовых файлов. Файл подаётся на вход программе-интерпретатору PHP, результатом обработки которого должен явиться, что называется, в «чистом» виде, тот самый html-файл, с которого мы начинали разговор. То есть, без фрагментов программного кода, который должен отработать на сервере.

Таким образом, можно сказать, что главным результатом действия программы на PHP должен являться выходной поток, представляющий собой документ html. Исключения из этого, опять же, бывают, о них в своё время мы поговорим, но пока ими можно пренебречь.

Здесь необходимое примечание: об html-документе в данном случае речь идёт условно, то есть, в выходном потоке запросто могут быть фрагменты скриптов, но скриптов, которые должны выполняться на клиентской стороне, web-браузером. Собственно, точно так же, как формируется программой на PHP html-код, может её формироваться и код, например, на Java-Script, включаемый в html-код документа, отправляемого web-сервером запросившему его пользователю. И наоборот, может генерироваться, и отправляться в браузер пользователя, и простой текстовый файл. Но, поскольку именно так происходит в большинстве случаев, будет считать, что в результате работы PHP-скрипта, мы получаем html-код.

Теперь, когда мы рассмотрели схему функционирования PHP в общем, вернёмся к возможностям. Итак, что мы можем сделать в программе, помимо того, что сформировать сложным образом оформленный и отформатированный в виде html выходной поток?

• во-первых, можем собрать и обработать данные, пришедшие вместе с запросом на страничку – отправленные, например, из заполненной html-формы. Причём, данная обработка может быть достаточно сложно организованной, если мы того захотим.
  
• во-вторых, можем произвольным образом работать с файловой системой, то есть, если web-серверу хватит на это прав, можем создавать, копировать, удалять, читать, писать, загружать файлы на сервере. Значительную часть этих операций можем делать и с каталогами.
  
• в-третьих, можем производить различные манипуляции с графическими изображениями различных форматов, в том числе – модифицировать их. Например, задача автоматического создания уменьшенных вариантов для предварительного просмотра загружаемых в галерею фотографий, не представляет ни малейшей сложности.
  
• в-четвёртых, мы имеем возможность поднимать информацию из различных серверных баз данных, а также – изменять при необходимости эту информацию.
  
• в-пятых, можем работать с сессиями, параметрами «cookies», а также различными параметрами web-сервера.
  
• в-шестых, мы имеем в своём распоряжении очень мощные и разнообразные механизмы для обработки строк – включая различные действия с регулярными выражениями.
  
• в-седьмых, мы можем различным образом обрабатывать документы XML, а также различные его приложения.
  
• в-восьмых, если нам это зачем-либо понадобится, можем пользоваться всеми механизмами IP-сокетов.
  

…и так далее, и так далее, и так далее…

В общем, по сути дела, главное, чего мы не можем сделать в PHP, это напрямую выдать сообщение пользователю. Впрочем, не можем мы этого сделать и в любой серверной программе, вне зависимости от того, на каком языке она написана.

Вышесказанное относится к функциональным возможностям, в синтаксическом же плане, программисты на PHP, в зависимости от их потребностей, могут пользоваться методами хоть структурного, хоть модульного, хоть объектно-ориентированного программирования. Здесь следует оговориться, что полноценная поддержка объектно-ориентированности появилась только в пятой версии – до этого, например, свойство полиморфизма выглядело весьма своеобразно.

4. Установка и проверка
   

Как уже говорилось, PHP может быть установлен в контекст различных web-серверов, которые, в свою очередь, работают под различными операционными системами. Тем не менее, наиболее часто вам придётся сталкиваться с установкой PHP в сервер Apache, причём, скорее всего, работающего в системе Windows.

Это можно с уверенностью заявить на том основании, что, во-первых, вашим, как web-разработчика, рабочим местом, будет, с наибольшей вероятностью, компьютер именно под управлением Windows, и чаще всего настраивать web-сервер вам придётся именно свой, локальный. На реальном web-сервере, работающем на Linux, или чём-то другом из семейства Юниксов, настраивать систему, скорее всего, будет профессиональный администратор, хотя, если вдруг это придётся делать вам же, то вы с удивлением обнаружите, что установка PHP в контекст сервера Apache там, практически, ничем не отличается – по крайней мере, в одном из вариантов.

Во-вторых, почему именно Apache, а не IIS? Вот здесь ответ простой: он и проще, и надёжнее, и гораздо экономичнее в плане отношения к вычислительным ресурсам, и, что в наше время становится актуально, бесплатен, и не требует никаких лицензий. В конце концов, если вам, в силу каких-нибудь обстоятельств непреодолимой силы (например, требований менеджера) захочется поставить PHP под IIS, вы, несомненно, сможете это сделать, воспользовавшись документацией.

Вообще, документация по установке к PHP прилагается очень объёмная, качественная, и описывающая, в частности, такие случаи, которые можно отнести к разряду совсем уж нереальных – например, что у вас будет web-сервер не Apache, не IIS, а что-то третье.

Фундаментально, существует два способа установки PHP на web-сервер: как CGI-приложение или как SAPI-модуль Apache. Функционально разницы никакой, то есть, в PHP установленном, как модуль, мы сможем с совершенно аналогичным результатом выполнять один и тот же PHP-скрипт.

Предварительно, следует заметить, что большие специалисты рекомендуют для удобства всё, что касается web-сервера, в том числе, и наш PHP, складывать в одну директорию, а директорию подключать, как виртуальный локальный диск (например, командой subst u: <путь к директории>). Предположим, что Apache у нас лежит в директории c:\Program Files\webserver\Apache, а для PHP мы отводим, соответственно, директорию c:\Program Files\webserver\php, которая, после подключения виртуальным диском стала u:\php.

Итак, вначале поставим PHP, как обработчик CGI. Как правило, «на входе» мы имеем архив, содержащий набор различных файлов. Этот архив следует распаковать в директорию, в которой, как мы постановили, будет лежать PHP. Кстати, на первом этапе из всех многочисленных файлов установочного архива, нам важны всего 3:

 php.exe — интерпретатор командной строки

 php4ts.dll — собственно ядро PHP

 php.ini-dist — конфигурационный файл, версия из дистрибутива

Если кого-то заинтересует вопрос, почему нам нужны всего 3 файла, а установочный комплект занимает от трёх до восьми мегабайт в архиве (в зависимости от версии и комплектации), то ответом будет: а потому, что в нём содержатся различные библиотеки расширений. Все эти расширения, предназначенные для поддержки XML, различных баз данных, кроме MySQL (она в PHP 4 включена в состав ядра), генерации картинок, и всего прочего, вы можете поставить позже в любой момент.

Следующим шагом предлагается скопировать файл php.ini-dist в директорию Windows, и переименовать его в php.ini.

Последующие настройки касаются только файла конфигурации Апача httpd.conf. Добавим mime-тип, соответствующий расширению программ PHP:

AddType application/x-httpd-php .php .php3 .php4 .phtml

Затем там же поставим действие (action) в соответствие указанному нами типу:



  Options ExecCGI



ScriptAlias "/_phpdir_/" "u:/php/"

Action application/x-httpd-php "/_phpdir_/php.exe"

Если делать всё совсем по правилам, то рекомендуется вставлять данный фрагмент непосредственно перед секцией Virtual Hosts, хотя в принципе, это уже не обязательно.

Теоретически, всё – теперь, если перезапустить Apache, PHP должен работать.

Тут же возникает логичный вопрос: как мы можем это проверить? Проверять рекомендуется следующим образом: создать в любом текстовом редакторе, хоть бы и notpad’е, файл test.php приблизительно следующего содержания:

Ceterum censeo Microsoft delendam esse

и разместить его в корневой директории документов вашего web-сервера. После этого в строке адреса вашего любимого браузера можете набрать

localhost/test.php

Если после этого в браузере вы увидите только текст фразы



Рис.1.1. Результат работы программы на PHP в браузере

значит, PHP успешно установлен, и мы можем приступать к работе.

Если хочется увидеть что-то более основательное, можно переписать нашу простейшую программу в виде:



и в результате её выполнения интерпретатор сообщит нам много ценного и интересного о себе, своих настройках и модулях расширения, а заодно о web-сервере, в контексте которого работает PHP.

Теперь о том, как поставить PHP в альтернативном варианте, варианте модуля Apache. Хотя многие компетентные люди с полным правом назвали бы альтернативным наш первый вариант, по той причине, что изначально PHP всё-таки был ориентирован только под Apache, Apache работал только под unix’ами, а под unix PHP подключается по логике, очень похожей на нашу установку модулем.

Точно так же копируем файлы из установочного комплекта в директорию, которую мы отвели для файлов PHP. На этот раз нам опять нужны, как минимум, 3 файла:

• php4ts.dll (собственно, ядро PHP)
  
• php4apache.dll (модуль для Апача)
  
• php.ini-dist (для того же, для чего и в прошлый раз)
  

Снова копируем php.ini в системную директорию, затем снова начинаем править httpd.conf - находим секцию "Dynamic Shared Object (DSO) Support" — её найти просто по строкам вида LoadModule ... Добавляем свою строчку:

LoadModule php4_module "путь-к-директории-php/php4apache.dll"

(в нашем случае – u:\php).

Теперь снова добавляем mime-тип

AddType application/x-httpd-php .phtml .php .php3 .php4

Если вы ранее подключили PHP как модуль CGI, то следует убрать строки, связанные с сопоставлением action для указанного типа. Ну и, собственно, всё – перезапускаем Apache, и проверяем на нашем тестовом файле, работает ли PHP.

Теперь о недостатках и преимуществах. Опыт показывает, что первый способ обычно начинает работать без проблем сразу, в то время, как второй всё-таки оказывается связан с некоторыми проблемами, особенно в случаях, если Apache установлен второй версии.

Со всех прочих точек зрения, предпочтительным является способ установки модулем. Он в разы выигрывает по скорости и по бережному отношению к ресурсам системы. Навряд ли Вы почувствуете это на локальном компьютере, но если на сервере окажется одновременно несколько пользователей, то разница даст себя почувствовать достаточно быстро.

Кроме того, установив PHP как модуль, вы получите возможность управлять некоторыми его параметрами из файлов .htaccess, и вообще будете избавлены от достаточно длинного ряда ситуаций, которые встречаются, возможно, и достаточно редко, но при встрече действуют на нервы очень сильно. Потому, за исключением случаев, когда нужно всё поставить очень быстро, рекомендуется всё-таки, ставить PHP, как модуль Apache.

В завершении разговора об установке, необходимо сказать, что, в конце концов, существуют и классические запускаемые windows-дистрибутивы, но для общего понимания, и более уверенного решения проблем в будущем, мы посчитали нужным рассмотреть ручную установку детально.

Дополнительно, следует сказать, что известно немало готовых комплектов из разряда «Джентльменский набор ленивого web-разработчика», которые с одного дистрибутива позволяют поставить не только Apache с PHP, но и MySQL заодно, но пользоваться ими или нет, предлагаю каждому решить самостоятельно. Наиболее популярные наборы такого рода носят название Денвер (ссылка скрыта) и Swissknife (ссылка скрыта).

5. Модули расширения
   

Теперь немного о том, почему же всё-таки непосредственно для работы PHP, хоть в том, хоть в другом варианте, нам нужны всего по три файла, а в дистрибутиве есть ещё много чего.

Основное, из прочего, что есть в дистрибутиве – различные модули расширения. Смысл данных модулей в том, что ядро PHP, содержит, конечно, много функций, но далеко не всё, что может понадобиться. Многие библиотеки функций вынесены в отдельные модули, без которых всё будет замечательно работать, пока нам не понадобится функциональность этих функций. Когда эта функциональность нам понадобится, нам придётся заняться подключением соответствующего модуля.

Как подключить модуль расширения? В принципе, достаточно просто. Самое главное условие в том, что эти самые модули расширения, находящиеся в установочном комплекте в каталоге extensions, и имеющие в внерсии для windows имена php_<личное имя>.dll, должны находиться в каталоге, который прописан в системных путях (PATH). То есть, для того, чтобы PHP смог их подключить, нужно либо каталог php/extesions прописать в списке системных путей, либо необходимые модули скопировать в какой либо прописанный каталог, например, windows/system32.

Затем, нам необходимо исправить файл конфигурации PHP. Люди, которые готовили установочный комплект, поступили очень разумно, и все присутствующие в комплекте модули, обычно уже прописаны в конфигураторе, но закомментированы. Наша задача сводится лишь к тому, чтобы найти в списке строку, содержащую подключение нужного нам модуля, и раскомментировать её. Например, для модуля расширения gd2, необходимая строка имеет вид:

extension=php_gd2.dll

После того, как мы исправили конфигуратор, если PHP у нас подключен, как модуль Apache, необходимо будет перезапустить Apache. Если PHP подключен, как обработчик CGI, это не обязательно – всё должно работать сразу с момента сохранения исправленного файла конфигурации.

Теперь немного о том, для чего какие модули нужны. Вообще, модулей там много, и значительная часть их становится нужна только в весьма экзотических ситуациях.

Так, уже упоминавшийся модуль расширения gd и дополненный функциями работы с новыми форматами gd2, служит для работы с графическими изображениями – в том смысле, что если нам надо не просто отправить картинку, а, скажем, изменить её размер, или что-то в неё дорисовать. Используя функции модуля gd, мы можем это сделать, и в нужный момент мы к этому ещё вернёмся.

Функции перекодировки строк содержатся в модуле iconv. Под перекодировкой в данном случае имеется в виду смена кодовых таблиц.

Модули mssql, oracle, sybase и ещё несколько, содержат функции для обращения скриптов к соответствующим серверам баз данных. Здесь нужно заметить, что функции для связи с MySQL встроены в состав ядра PHP.

Модуль Zlib позволяет работать из программы на РНР с архивами в формате Gzip, а модуль libswf - с Flash-презентациями, создавая и редактируя их также прямо из программы на РНР.

Чуть более сложная ситуация с использованием XML. Поддержка XML в модулях расширения PHP, конечно, есть, но по какой-то причине получается, что в разных версиях модуля domxml (входящих в различные установочные комплекты даже одинаковых версий PHP) для разбора XML-документов применяется разный набор функций.

Соответствующие модули расширения существуют для компрессии данных алгоритмом zip, доступа к функциям Win API и web-серверов, шифрования, работы с форматом pdf, и много чего еще.

Как правило, в описании функций говорится о том, какой модуль должен быть подключен для того, чтобы данной функцией можно было воспользоваться.

Здесь также следует указать, что разные установочные комплекты могут нести в своём составе различный набор расширений. И, тем более, на реальных web-серверах может быть установлен различный набор расширений. Потому, если при разработке проекта вам приходится пользоваться теми или иными функциями из модулей расширения, следует заранее уточнять, подключено ли соответствующее расширение на том сервере, где будет размещаться проект, и если не подключено, то реально ли его подключить.

Напоследок следует заметить, что модули расширения PHP, при желании, могут быть по необходимости разработаны самостоятельно – все интерфейсы открыты, все описания в природе существуют. Однако, задача эта достаточно экзотична, и в рамках нашего курса мы этим заниматься не будем.

6.