От Лапши До Ингредиентов Или Слушайся Родителей!

Родители всегда учат своих детей (на то они и родители).

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

Например, моя мама всегда говорила мне три вещи:

1. Не переедайте на ночь 2. Не играйте в азартные игры 3. Не создавайте свои собственные PHP-фреймворки.

И теперь я понимаю, что мне не следовало ее слушать.

А потом.

Как давно это было.

Хотя и не так давно, всего полтора года назад. Молодая команда бывших студентов решила заняться разработкой веб-сервисов.

Web 2.0, Ajax, Rich Client, Mashup, Облако тегов — эти слова не сходили с моего языка, а окружающие думали, что это оскорбительные ругательства, и часто меня били.

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

Сразу возник вопрос: на чем писать наши «нетленные»? В языке мы даже не сомневались — PHP, конечно.

Почему? Потому что вся команда знала PHP, а он сам Джоэл Я написал, что вам нужно развиваться на том языке, который вы знаете.

Второй вопрос был: как написать? Выбор был небольшой:

1. Пишите на чистом PHP, ни о чём не думая (то есть пишите «лапшой»).

2. Взять какой-нибудь сторонний фреймворк.

3. Напишите свой собственный движок.

Первое предложение было сразу отклонено.

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

Сторонних фреймворков, отвечающих нашим запросам, мы не нашли, хотя очень старались (было время).

Поэтому для начала мы создали ветку фреймворка в SVN и сели придумывать ее название и архитектуру.

После многочисленных споров, ругани и драк было решено назвать проект Adept.

От лапши до ингредиентов или Слушайся родителей!

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

С архитектурой ситуация также была непростой.

Сначала мы пошли по проторенной тропе MVC. Однако вскоре мы поняли, что классическая архитектура MVC не облегчает разработку.

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

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

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

Более того, HTML не особенно подходит для программирования сложных пользовательский интерфейс компоненты (ведь это язык разметки текста), поэтому для реализации всяких меню, табуляторов и т.п.

требуется много времени и сил у программистов.

Мы решили сделать разработку интерфейсной части такой же простой, как и в десктопных приложениях.

Мы отказались от классического MVC, заменив его компонентной архитектурой.

То есть мы решили создать набор стандартных UI-компонентов (кнопок, флажков, переключателей, текстовых полей, таблиц), как в десктопных приложениях, и просто построить интерфейс из этих компонентов.

Мы также решили реализовать модель событие/слушатель.

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

То есть создать такой Framework, чтобы программисты кодировали только бизнес-логику (чем они очень любят заниматься), даже не задумываясь о том, «как я могу сделать календарь ?.

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

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

Е.

следовать стандартам).

И вот совсем недавно к нам пришла мысль: «Может, это кого-то еще заинтересует? Может быть, нам стоит показать это другим людям? Однако это оказалось довольно сложной задачей (сложнее разработки).

Необходимо написать документацию, подчистить код, «подчистить» иерархию объектов, создать сайт поддержки и т. д. И тогда возникает вопрос: «А нужно ли этоЭ» Нужен ли PHP-сообществу такой фреймворк? (смотря на обсуждения Здесь или Здесь , начинаешь думать наоборот).

Не найдя ответа внутри себя, мы решили спросить вас, хабралюди.

Ну, что ты скажешь? Пожалуй, прикреплю ссылку: http://adept-project.com Теги: #adept-project #php #веб-разработка #framework #Компоненты #php

Вместе с данным постом часто просматривают: