Примечание: мини-статья написана для новичков

Давайте посмотрим вокруг: форумы, интернет магазины, гостевые книги и т.д. используют регистрацию и последующую авторизацию пользователей. Можно даже сказать, что это почти необходимая функция каждого сайта (только если это не домашняя страничка Васи Пупкина или не визитная карточка, какой-нибудь небольшой компании). Сегодня я хочу поделиться со всеми новичками информацией, о том, как лучше это все реализовать.

Предисловие

В этом руководстве Вы узнаете, как построить простую систему по архитектуре MVC (Model-View-Controller, Модель-Отображение-Контроллер) на PHP 5.1 с использованием возможностей библиотеки SPL (Standard PHP Library, Стандартная Библиотека PHP).

И так. Объясняю популярно. Ибо сам пока разобрался потратил ни 10 минут. Делаем на примере условного сайта "Travel".

• Движок CakePHP [cakephp/cake и cakephp/vendors] я перенёс(!) в /var/www/cake.core (/var/www у меня apache wwwroot) — то есть, этот движок будет использоваться для всех проектов и не будет меняться до следующей версии CakePHP.
• Содержимое cakephp/app/webroot переносим(!) в /var/www/travel (в этой папке у нас будут все css, images, js, uploads и т.д.)
• Всё из cakephp/app (там уже нет webroot, мы его прошлым шагом от туда перенесли) переносим(!) в /var/www/travel.app (там у нас будет вся логика и темплейты. MVC то есть).

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

Объектно-ориентированное программирование — как стиль жизни. Это не просто применение конструкций типа class или interface — это способ мышления, когда любая сущность программы является не просто набором инструкций, а представляет из себя \«живое\» существо…

Думаю напоминать что такое ООП, в рамках данной статьи, будет лишним, посему перейду сразу к проблематике вопроса.

Разработчики, пришедшие в PHP из других языков программирования, и столкнувшиеся в нем (в РНР. тут и далее буду подразумевать РНР5 — прим.) с классами, недоумевают как их вообще возможно использовать. А все из-за того, что время жизни скрипта на РНР гораздо меньше, чем у прикладного ПО и составляет всего один цикл работы, в то время как прикладное ПО может жить и взаимодействовать со своими компонентами много дольше. В итоге миру является код, в котором классы реализуют всего-навсего отсутствующие в РНР namespaces.

Отчего-то всегда хотел сделать свой сервис для загрузки файлов. Всевозможные slil/zalil не устраивали своей скоростью. ifolder — обилием рекламы. Пользовался не очень популярным (от этого он ни чуть хуже не становился) сервисом up.spbland.ru. Но это как-то не правильно. И тут я решил написать свой сервис. Не буду вдаваться в подробности и рутину, только концепция.

PHP один из самых популярных скриптовых языков программирования. Почти 60% веб серверов используют PHP.Миллионы веб-сайтов и веб-приложений разрабатываются на PHP каждый месяц.

PHP изначально разрабатывался как простая замена языку Perl, и уже спустя пару лет он стал чрезвычайно мощным и популярным. Язык PHP, сам по себе очень похож на ANSI C.
Одна из причин почему PHP стал таким популярным это его короткий период обучения.

Изучение PHP абсолютно не тяжёлое занятие, особенно если вы хорошо знакомы с синтаксисом Java или C.

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

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

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

Итак… Приступим.
В последнее время я встретил сразу 2 реализации многопоточности на Хабре. Немного подумав я решил написать и свой вариант.
Но так как у меня нет возможности использовать PCNTL библиотеку, то мне пришлось извратиться…

Задача: реализация многопоточности на PHP (threads)

Издержки: нет модуля PCNTL ( build w/o PCNTL )

Решение: чистый PHP + Unix ( pure PHP + Unix )

Суть многопоточности (для приложения) состоит в том, что процесс может состоять из нескольких (однотипных) потоков, выполняющихся «параллельно», то есть без упорядочивания по времени — выполнился один, пошел следующий. Использование многопоточности позволяет ускорить выполнение задачи и/или снизить нагрузку, таким образом, улучшая быстродействие самого приложения.

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

Я рассмотрю простой пример, как можно достичь эмуляции многопоточности в PHP.

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

Различные веб-приложения позволяют пользователям загружать файлы. Форумы позволяют пользователям загружать «аватары». Фотогалереи позволяют загружать фотографии. Социальные сети предоставляют возможности по загрузке изображений, видео, и т.д. Блоги позволяют загружать опять же аватарки и/или изображения.

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

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

Это вторая часть перевода. Начинать прочтение лучше с первой.

Итак, после применения описанных в первой части методов, мы можем прекратить волноваться? К сожалению, нет. То, какие расширения файла будут переданы транслятору PHP, будет зависеть от конфигурации сервера. Разработчик часто не знает и не контролирует конфигурацию веб-сервера. Мы видели веб-серверы, с такой конфигурацией, что файлы .html и .js выполнялись как php. Некоторые веб-приложения могут потребовать, чтобы файлы .gif или .jpeg интерпретировались PHP (это часто случается, когда изображения, например графы и диаграммы, динамически строятся на сервере самим PHP).

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

Что такое веб-сервисы?

Прежде всего, веб-сервисы (или веб-службы) — это технология. И как и любая другая технология, они имеют довольно четко очерченную среду применения.

Если посмотреть на веб-сервисы в разрезе стека сетевых протококолов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP.

С другой стороны, если гипотетически разделить Интернет на несколько слоев, мы сможем выделить, как минимум, два концептуальных типа приложений — вычислительные узлы, которые реализуют нетривиальные функции и прикладные веб-ресурсы. При этом вторые, зачастую заинтересованы в услугах первых.

Но и сам Интернет — разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки.

Чтобы связать все это и предоставить возможность одним приложениям обмениваться данными с другими, и были придуманы веб-сервисы.

«Совершенный Ajax» — новый подход к построению web-приложений, при котором web-сервер не генерирует ни строчки HTML-кода и взаимодействует с внешним миром только посредством web-служб; а клиентский интерфейс реализуется только на основе клиентских HTML, CSS, JavaScript.

Статья состоит из двух частей. В первой части — более живой и провокационной я постараюсь заинтересовать проблемой, рассказать о технологии «Совершенный Ajax» и показать ее применение на примере нашего проекта «Система Интерактивного Тестирования Знаний “Синтез”» (который имеет ряд интересных особенностей, таких, как использование серверного JavaScript на платформе Mozilla Rhino, прототипно-ориентированная ORM и поддержка SPARQL — языка запросов к Semantic Web).

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

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


Попробуйте угадать: к какой архитектуре относятся web-приложения?

К клиент-серверной говорите? Я ожидал, что Вы так ответите :-)

Что ж, давайте разберемся. В клиент-серверной архитектуре выделяют:

• Сервер — отвечает за хранение данных и реализацию бизнес-логики приложения.
  
  
• Клиент — отвечает за взаимодействие с пользователем ^[1].
  
  

Реализация бизнес-логики на сервере и взаимодействие с пользователем на клиенте четко разделены.

Преимущества клиент-серверной архитектуры очевидны; мы их все знаем:

1. Бизнес-логика не смешивается с пользовательским интерфейсом.
2. Можно реализовать несколько клиентов с разными пользовательскими интерфейсами: интерфейс командной строки, оконный Windows-интерфейс, Flash, web-интерфейс, мобильный интерфейс и т.д.
3. Клиентский компьютер не требователен к ресурсам;
4. И т.д.

Но, относятся ли web-приложения к клиент-серверной архитектуре?

Действительно, в web-приложениях есть сервер, отвечающий за бизнес логику приложения.

Но! За реализацию интерфейса отвечает не клиент, а тоже сервер. На сервере происходит обработка клиентской формы. Сервер генерирует HTML-код пользовательского интерфейса.

Клиент, т.е. браузер лишь визуализирует уже готовый HTML-код интерфейса. Это, фактически, то же самое, что прицепить к серверу монитор и объявить этот монитор клиентом…

Preamble

В статье рассматриваются новые интересные возможности, которые предоставит пятая версия стандарта HTML. Приводится несколько примеров кода с применением новых тегов, а так же поясняются понятия HTML- и XML-сериализации с описанием преимуществ применения каждой из них.

Вводная «лирическая» часть текста сокращена, т.к. она во многом пересекается с ранее опубликованным обзорным постом об HTML 5, в котором был приведен фрагмент интервью того же автора.

Автор: Лахлан Хант, http://lachy.id.au
Оригинал: http://www.alistapart.com/articles/previewofhtml5
Перевод: Александр Мусаев, http://paradigm.ru

Введение

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

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

Полиморфизм — одна из трех основных парадигм ООП. Если говорить кратко, полиморфизм — это способность обьекта использовать методы производного класса, который не существует на момент создания базового. Для тех, кто не особо сведущ в ООП, это, наверно, звучит сложно. Поэтому рассмотрим применение полиморфизма на примере.

Эта «небольшая» статейка является развитием темы затронутой в этой статье.
Как известно, PHP зародился довольно давно и уже тогда возник вопрос, что делать с возникающими ошибками. Perl, который является несомненным прародителем PHP по умолчанию не имел какой-либо системы обработки ошибок. При возникновении любой ошибки сервер выбрасывал 500-ю ошибку и на этом все заканчивалось. Поэтому Warnings, Fatal Errors и Notices были настоящим прорывом в облегчении и без того нелегкого труда программиста. Однако время шло, механизмы PHP не менялись, а технологии, как известно, на месте стоять не любят.

Статейка старенькая, но думаю до сих пор актуальная

Cлишком часто я в последнее время слышу слово «шаблонизатор». Не утихают споры между сторонниками разных шаблонных движков. Одни говорят что логика в шаблонах это хорошо, другие считают что это зло. Даже сейчас очень часто встречаются проекты, написанные вообще без применения какого либо шаблонизатора. Но в этой статье я не буду предпринимать попыток стать на сторону одной из сторон. Я не буду вам доказывать преимущества ни одного из подходов. Я просто постараюсь рассказать обо всех из них с точки зрения теории. Эта статья не о конкретных программных продуктах, а о способах выделения логики представления в ваших приложениях.

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

Update (2014): Это статья 2007 года, которая, к моему удивлению, до сих пор пользуется спросом. По этой причине я обновил её в соответствии с новыми правилами оформления постов на Хабре, и добавил подсветку синтаксиса для примеров кода. Если кому-то захочется что-то добавить или исправить, исходник текста с хабра-разметкой выложен в открытый доступ: gist.github.com/dreikanter/2b4ee996d7a775e707d7

Аннотация от переводчика

PHP — один из самых широко распространенных языков разработки веб-приложений и при этом один из самых спорных. Я очень часто видел негативное отношение к этой технологии, да и недостатки, провоцирующие это отношение — не для кого не являются секретом. Тем не менее, PHP активно эволюционирует и во многих отношениях постепенно становитс лучше. Одним из серьезных шагов его развития, на мой взгляд, является появление MVC-фреймворков, призванных систематизировать процесс разработки веб-приложений и приучить к порядку разработчиков, которым зачастую здорово не хватает силы воли, чтобы при всей предоставляемой языком свободе, сохранить грамотную и красивую инфраструктуру разрабатываемого ПО (сразу уточню, что последнее утверждение субъективно и основано исключительно на виденном мной коде различных программных решений).

В последнее время я активно заинтересовался архитектурой MVC и сделал свою собственную реализацию фреймворка на этой концепции для PHP4. Совсем недавно на глаза попался первый официальный релиз Zend Framework, о котором я давно слышал, но все руки не доходили с ним поиграть. Для PHP существуют и другие подобный библиотеки, но в данном случае привлек бренд.