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

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

От программистов обычно ждут строгого следования ТЗ. Если, не дай бог, к составлению ТЗ привлекают дизайнера, то всё обычно сводится к тому, чтобы соответствовать рисованным макетам, а программирование — ну после как-нибудь прикрутите. Это конечно, колоссальная ошибка, потому что перед тем, как что-то «рисовать» и серьёзно «программировать», необходимо опробовать идею/задачи в черновом варианте. Этот этап называется прототипированием.

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

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

Через это прошли все фреймворки, системы, библиотеки (любого ЯП) и т.п., которые продолжают развиваться. По мере роста, вначале идёт эволюционный подход, когда возможностей хватает, но потом резкий скачок к новой версии. Для того, чтобы упростить такие переходы, архитектура приложения должна изначально подразумевать такую «версионность».

При разработке php-проекта часто возникает потребность разделить его на небольшие части — модули. Слово «модули» довольно расплывчато и в разных случаях может трактоваться по своему, но в данном случае речь идёт только о том, что модуль — это некий код, который может представлять собой единую сущность.

Программно модуль может быть набором классов, функций и файлов. Он может содержать html-код, css-стили, js-скрипты, изображения и т.п. То есть не важно как в реальности реализован модуль, главное это то, что мы можем его воспринимать как единое целое.

Когда в проекте много php-классов, то возникает проблема подключения их файлов. Например есть классы Class1 и Class2. Для того, чтобы их использовать, вначале нужно подключить их php-файлы. Само по себе подключение — это обычные require или include, поэтому задача сводится к тому, чтобы указать правильный путь к php-файлу. По мере, того как классов становится всё больше, возникает серьезная проблема с подключением каждого файла класса. В идеале процесс подключения должен быть автоматизирован и в PHP для этого используется механизм автозагрузчика.

Автозагрузчик будет срабатывать каждый раз, когда в коде встретится неизвестный класс. Сам по себе автозагрузчик представляет собой обычную функцию, которая и выполняет подключение файла с помощью require. Функция автозагрузчика должна быть зарегистрирована через специальную функцию spl_autoload_register. При этом функций можно зарегистрировать несколько — PHP последовательно их выполнит пока не подключит файл с нужным классом.

Давайте рассмотрим несколько примеров, чтобы лучше понять как это всё работает (исходные файлы можно скачать в конце статьи).

Пока я не стал баловаться программированием на Javа, особо не задумывался над использованием MVC в PHP. Обычно действуешь по своему опыту или как это принято в php-фреймворке (или CMS, не важно). Тем более почти все фреймворки декларируют свою преданность концепции MVC: дескать вот у нас всё сделано правильно, по теории.

После Java, где объектное программирование возведено почти в абсолют, MVC в PHP выглядит уже достаточно «бледно», пытаясь хоть как-то соответствовать этой концепции. Интересно ещё и то, что php-разработчики Model-View-Controller видят по разному и не всегда верно.

Сейчас очень много разных CMS. Среди них есть какие-то популярные и не очень. Мне по роду программистской деятельности приходится просматривать много разных «движков», php-фреймворков, поэтому в какой-то мере я в них могут соориентироваться и понять стоит ли систему использовать. Для обычного потребителя критерии оценки, как правило, очень субъективны и строятся на чужих мнениях, авторы которых, в общем-то, сами довольно поверхностно разбираются в этом вопросе.

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

Читать дальше...

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

Реализация AJAX довольно сложна с технической точки зрения. На самом деле происходит работа API XMLHttpRequest, который и выполняет всю работу. Чтобы упростить код, используются функции-«обертки», которые освобождают нас от сложного программирования XMLHttpRequest. В jQuery для этого используются функци ajax, а также её «модификация» post. При этом, если jQuery не нужна, то в Сети можно найти другие библиотеки, реализующие функционал AJAX, например Selector (которая вообще выступает как легковесная замена jQuery).

Не зависимо от используемой библиотеки, основные принципы отправки даных с помощью Аякса будут едиными. Я буду всё показывать на примере jQuery. В конце статьи вы найдете ссылку на zip-архив со всеми примерами.

Читать дальше...