Comments 121
Я бы поспорил с скоростью процедурности vs ООП, все закешируется и разницы никакой не будет.
Покажите тесты в сравнении с какими нибудь микро-фреймворками.
global — зло, судя по коду — вы их все копипастили из функции в функцию, потому что не все они используются.
В общем советую прочесть github.com/fabpot/Create-Your-Framework — создатель симфони описывает как стоит создавать фреймворк, и как делать явно не стоит.
Покажите тесты в сравнении с какими нибудь микро-фреймворками.
global — зло, судя по коду — вы их все копипастили из функции в функцию, потому что не все они используются.
В общем советую прочесть github.com/fabpot/Create-Your-Framework — создатель симфони описывает как стоит создавать фреймворк, и как делать явно не стоит.
Да, на счет global вы правы — я много чего менял и в некоторых местах остались вызовы никак не используемых глобальных переменных. Постараюсь почистить. А так основных глобальных переменных всего 3 — $_response, $_values и $_view. Есть еще несколько используемых в меньшей мере и с ними действительно надо что-то делать.
А за ссылку спасибо, обязательно покурю.
А за ссылку спасибо, обязательно покурю.
global это нормально — если применять там где нужно. Это такой Registry, только в привычном виде.
Просто есть люди, типа создателя симфони, которые все хотят абстрагироваться от ЯП и делать сферических коней в вакууме, вместо того чтобы использовать инструмент на полную мощь и делать полезный функционал.
При этом ООП использовать тоже нужно. Иначе рождается на свет такое недоразумение как ваш «фрейморк» (набор файлов и пара функций), здравые идеи конечно есть — типа файл как контроллер, конфиги в виде php). Но зачем он тогда в принципе и такая структура вообще? Если процедурный стиль и можно использовать копипаст по шаблону и далее:
— контроллер — файл со свитчкейсом и набор функций экшонов или разные файлы для экшонов как у вас.
— content() -> include $content
— headTitle -> $title = ‘...’;
->
— роут выкинуть нафиг (опять какой-то перебор в цикле, похоже что нет ни одного фрейморка с продвинутым роутингом, чтоб без регулярок и перебора) — тогда лучше уж разбор параметров средствами сервера делать (mod_rewrite, etc)
— лейауты, снова include ‘layouts/default.phtml (сюрприз!);
— PDO, переменные $_POST, $_GET,http://www.php.net/manual/ru/ref.filter.php
и т.п. заместо ненужной кустарщины.
Просто есть люди, типа создателя симфони, которые все хотят абстрагироваться от ЯП и делать сферических коней в вакууме, вместо того чтобы использовать инструмент на полную мощь и делать полезный функционал.
При этом ООП использовать тоже нужно. Иначе рождается на свет такое недоразумение как ваш «фрейморк» (набор файлов и пара функций), здравые идеи конечно есть — типа файл как контроллер, конфиги в виде php). Но зачем он тогда в принципе и такая структура вообще? Если процедурный стиль и можно использовать копипаст по шаблону и далее:
— контроллер — файл со свитчкейсом и набор функций экшонов или разные файлы для экшонов как у вас.
— content() -> include $content
— headTitle -> $title = ‘...’;
->
— роут выкинуть нафиг (опять какой-то перебор в цикле, похоже что нет ни одного фрейморка с продвинутым роутингом, чтоб без регулярок и перебора) — тогда лучше уж разбор параметров средствами сервера делать (mod_rewrite, etc)
— лейауты, снова include ‘layouts/default.phtml (сюрприз!);
— PDO, переменные $_POST, $_GET,http://www.php.net/manual/ru/ref.filter.php
и т.п. заместо ненужной кустарщины.
Насчет сферических коней не соглашусь, есть одна маленькая, но старая как мир проблема под названием «конфликты пространства имен». И именно решению этой проблемы посвящены эти «сферические кони» симфы.
p.s. Задумался над роутингом без регулярок и цикла, завис, т.к. любой более-менее продвинутый роутинг включает в себя:
1. Возможность определения масок запросов
2. Возможность последовательного применения правил.
Если вы это можете решить без цикла и регулярок просветите пожалуйста как.
p.s. Задумался над роутингом без регулярок и цикла, завис, т.к. любой более-менее продвинутый роутинг включает в себя:
1. Возможность определения масок запросов
2. Возможность последовательного применения правил.
Если вы это можете решить без цикла и регулярок просветите пожалуйста как.
1. Маски, в принципе, можно и без регулярок, но хоть сколь-нибудь развитые скорее всего вызовут реакцию «автор не читал раздел о PCRE?»
2. Не последовательный перебор правил, а рекурсивный
Хотя, конечно, это скорее из разряда " можно сделать так, то не нужно". :)
2. Не последовательный перебор правил, а рекурсивный
Хотя, конечно, это скорее из разряда " можно сделать так, то не нужно". :)
> «конфликты пространства имен»
можно свободно использовать неймспейсы без всяких фреймворков.
> Задумался над роутингом без регулярок и цикла
написал же — средствами сервера.
любой популярный сервер (apache, nginx, iis) умеет нормальный роутинг
Как говорят — «Со своим самоваром в Тулу не лезь».
можно свободно использовать неймспейсы без всяких фреймворков.
> Задумался над роутингом без регулярок и цикла
написал же — средствами сервера.
любой популярный сервер (apache, nginx, iis) умеет нормальный роутинг
Как говорят — «Со своим самоваром в Тулу не лезь».
написал же — средствами сервера.
любой популярный сервер (apache, nginx, iis) умеет нормальный роутинг
Что вы понимаете под роутингом, который умеют веб-сервера? Как веб-сервер преобразует GET /books в вызов, например, функции books_show_list(), GET /books/7 в вызов функции books_show_detail(7), а GET /books/7/authors в author_show_list_for_book(7)? Максимум что может сделать сервер — это передать транслятору PHP определенный файл с различными параметрами, но о сущностях PHP типа функция или метод он не знает ничего. А если вы захотите передавать имя функции в, скажем, переменных окружения ($_ENV['controller '] установить, например), то придется писать что-то преобразующее это имя в вызов функции и это «что-то» будет называться роутингом и будет в приложении два роутинга. Зато без регулярок на PHP (но с регулярками в конфигах серверов, причем конфиги серверов как правило сложнее). А как будете решать задачу генерации урлов? Парсить конфиги nginx, apache или IIS? А если внезапно lighttpd? А при обновлении что будете писать клиентам? «Отредактируйте под рутом /etc/nginx/sites-enabled/example.com добавив 7 новых локейшенов из аттача, не забыв исправить пути на свои»? А он вам в ответ «нет у меня такого пути, nginx точно есть, а пути такого нет».
Имхо, веб-серверам не стоит доверять задачу роутинга, максимум локальную задачу преобразования ЧПУ вида /books/7 во что-то вроде index.php?query=/books/7 или index.php/books/7 (предпочтительней). Иначе сложность поддержки возрастает очень сильно. Хотя бы просто поддерживать конфиги для пары популярных серверов уже проблематично будет.
не точно написал — имел ввиду реврайт на файлы и параметры в привычном виде.
а дальше все очевидно как использовать.
а дальше все очевидно как использовать.
>А если вы захотите передавать имя функции в, скажем, переменных окружения.
($_ENV['controller '] установить, например),
Не представляю зачем это бы нужно было бы и чем не угодил $_GET — так что не захочу. Не надо решать несущесвующих проблем.
>А как будете решать задачу генерации урлов
Писать их в коде, очевидно же. Структура простая — контроллер/экшн или модуль/контроллер/экшн.
>А при обновлении что будете писать клиентам?
>Парсить конфиги nginx, apache или IIS? А если внезапно lighttpd?
>А он вам в ответ «нет у меня такого пути, nginx точно есть, а пути такого нет».
Ну а если скажет что php нет у него, что тогда? Опять какая-то проблема из пальца высосаная. Клиент правящий конфиги — это сильно конечно. Клиентам вообще на такие тонкости пофиг должно быть. Им надо функционал рабочий чтобы был и все, а это уже задача разработчиков — как реализовать, какие требования к ПО должны быть.
($_ENV['controller '] установить, например),
Не представляю зачем это бы нужно было бы и чем не угодил $_GET — так что не захочу. Не надо решать несущесвующих проблем.
>А как будете решать задачу генерации урлов
Писать их в коде, очевидно же. Структура простая — контроллер/экшн или модуль/контроллер/экшн.
>А при обновлении что будете писать клиентам?
>Парсить конфиги nginx, apache или IIS? А если внезапно lighttpd?
>А он вам в ответ «нет у меня такого пути, nginx точно есть, а пути такого нет».
Ну а если скажет что php нет у него, что тогда? Опять какая-то проблема из пальца высосаная. Клиент правящий конфиги — это сильно конечно. Клиентам вообще на такие тонкости пофиг должно быть. Им надо функционал рабочий чтобы был и все, а это уже задача разработчиков — как реализовать, какие требования к ПО должны быть.
Не представляю зачем это бы нужно было бы и чем не угодил $_GET — так что не захочу. Не надо решать несущесвующих проблем.
ENV или GET без разницы — всё равно в коде нужно анализировать, повторно, а к ENV больше доверия, чем к GET
Писать их в коде, очевидно же. Структура простая — контроллер/экшн или модуль/контроллер/экшн.
Нормальная система роутинга позволяет указать в шаблоне нечто вроде url('controller', 'action', ['param1', 'param2']) и получить в html нормальный ЧПУ, а не /controller/action?param1¶m2
Клиент правящий конфиги — это сильно конечно.
А для чего конфиги делаются? Как раз, отчасти, чтобы клиент их мог править, не залезая в основной код.
роут выкинуть нафиг (опять какой-то перебор в цикле, похоже что нет ни одного фрейморка с продвинутым роутингом, чтоб без регулярок и перебора) — тогда лучше уж разбор параметров средствами сервера делать (mod_rewrite, etc)
Гм. Ну у кого нет, у кого есть. Но это не то, чем я горжусь-не-могу.
Выглядело как попытка создания класса, сформированного из имени, полученного через GET/POST, проверкой на то, что данный класс является экземпляром определённого интерфейса, и последующим вызовом методов данного интерфейса. Как-то так.
Ну и там ещё было всякого, да.
За ссылку большое спасибо.
github.com/hell0w0rd/Create-Your-Framework/tree/rus — пользуясь случаем, приглашаю перевести это руководство, у самого времени не хватает, перевел только вступление.
Первые 6 частей уже переведены.
У меня сразу такая мысль возникла.
Угу. Разницы в скорости не будет, а отсутствие наличия порядка превратит проект в еще один (более продвинутый) Drupal :)
С одной стороны- человек молодец, на правильном пути- учится, применяет на практике, старается все обобщить и оптимизировать. Каждый должен написать _свой_супер_мега_фреймворк_ (ну или вовремя бросить это занятие). С другой стороны- если каждый будет о своих достижениях статьи писать, это ж сколько времени нужно чтобы хотя-бы прочитать это все! :)
Настоятельно рекомендую поизучать другие языки программирования — откроете для себя много интересного и избавитесь от некоторых заблуждений.
Это ни в коем разе не совет «избавиться от этого гнусного пхп», а скорее для того, чтобы расширить собственный кругозор. Качество и красота кода зависят от него в первую очередь, а от выбранного языка/фреймворка во вторую.
Это ни в коем разе не совет «избавиться от этого гнусного пхп», а скорее для того, чтобы расширить собственный кругозор. Качество и красота кода зависят от него в первую очередь, а от выбранного языка/фреймворка во вторую.
Не могли бы подтолкнуть в нужном направлении?
Из других языков я пробовал С++ и Delphi, совсем немного знаком с Python и Java, в веб-направлении пробовал NodeJS и RoR, остановился пока на рельсах, продвигаюсь потихоньку.
Из других языков я пробовал С++ и Delphi, совсем немного знаком с Python и Java, в веб-направлении пробовал NodeJS и RoR, остановился пока на рельсах, продвигаюсь потихоньку.
Нода существенно отличается от рельс. Это целая платформа. В ноде можно собрать проект из модулей/библиотек стандартных. Можно использовать готовый небольшой фреймворк Express, который как раз таки вобрал в себя все нужные либы для работы с веб и использует простую и гибкую архитектуру CommonJS. ООП там по большей части нет. Так что как вариант для попробовать очень даже.
Рельса это каркас из гемов ( тех же модулей), но объем этих гемов в разы больше, того что есть в Express например. Соответственно функционала из коробки так же в разы больше. В Рельсе так же очень развита культура тестирования.
В остальном попробуйте функциональные языки, clojure, haskell. Там тоже есть фреймворки для веба и нет ООП )) В этом смысле хаскель очень хорошо вправит мозги и покажет, каким программирование может быть на самом деле.
Рельса это каркас из гемов ( тех же модулей), но объем этих гемов в разы больше, того что есть в Express например. Соответственно функционала из коробки так же в разы больше. В Рельсе так же очень развита культура тестирования.
В остальном попробуйте функциональные языки, clojure, haskell. Там тоже есть фреймворки для веба и нет ООП )) В этом смысле хаскель очень хорошо вправит мозги и покажет, каким программирование может быть на самом деле.
Обязательно посмотрите Go.
Ещё Lua достаточно интересный язык своим минимализмом высокой производительностью по сравнению с другими динамическими языками.
Ещё Lua достаточно интересный язык своим минимализмом высокой производительностью по сравнению с другими динамическими языками.
nodejs интересен своей компактностью и одновременно наличием всего необходимого, причем, без излишеств.
rails, само собой, подход достойный внимания, только не надо перенимать оттуда привычку патчить core компонеты по поводу и без повода :)
python хорош своей простотой и «чистотой» по сравнению с рубями, здесь полезно освоить Django (сайтики строгать) или Tornado, если хочется нетрадиционностей.
Отдельно рекомендую обратить внимание на Clojure — и даже не на сам язык (он неопытных, как правило, не вставляет поначалу), а на те видео, где Рич рассказывает про правильный подход к программированию.
rails, само собой, подход достойный внимания, только не надо перенимать оттуда привычку патчить core компонеты по поводу и без повода :)
python хорош своей простотой и «чистотой» по сравнению с рубями, здесь полезно освоить Django (сайтики строгать) или Tornado, если хочется нетрадиционностей.
Отдельно рекомендую обратить внимание на Clojure — и даже не на сам язык (он неопытных, как правило, не вставляет поначалу), а на те видео, где Рич рассказывает про правильный подход к программированию.
Понравилось, но использовать не буду =)
Очень клёво что ты стараешься самостоятельно чему-то научиться, но если честно я бы посоветовал пойти другим путём — попробуй связаться с авторами фреймворка Yii и предложи им свою помощь в разработке, напросись на участие в популярный OpenSource проект. Результатом станут сразу несколько плюсов:
— получишь опыт командной разработки;
— будешь видеть что такое по настоящему хороший код;
— тебе постоянно будут подсказывать где и что ты накосячил и соответственно ты с каждым разом будешь писать всё более лучший код;
— хороший опыт работы с GIT;
— посильная помощь ребятам в разработке новой версии Yii2;
— клёвая строчка в резюме.
Из минусов хотелось бы отметить разве что… скорее всего придётся забросить собственный проект, но я бы на твоём месте поступил именно так =\
Это конечно только моё личное мнение и оно может быть ошибочным.
Очень клёво что ты стараешься самостоятельно чему-то научиться, но если честно я бы посоветовал пойти другим путём — попробуй связаться с авторами фреймворка Yii и предложи им свою помощь в разработке, напросись на участие в популярный OpenSource проект. Результатом станут сразу несколько плюсов:
— получишь опыт командной разработки;
— будешь видеть что такое по настоящему хороший код;
— тебе постоянно будут подсказывать где и что ты накосячил и соответственно ты с каждым разом будешь писать всё более лучший код;
— хороший опыт работы с GIT;
— посильная помощь ребятам в разработке новой версии Yii2;
— клёвая строчка в резюме.
Из минусов хотелось бы отметить разве что… скорее всего придётся забросить собственный проект, но я бы на твоём месте поступил именно так =\
Это конечно только моё личное мнение и оно может быть ошибочным.
Рад что понравилось)
Совет интересный, быть может действительно попробую к какому-нибудь проекту подключиться, но чуть позже =) Как раз из-за собственных проектов
Совет интересный, быть может действительно попробую к какому-нибудь проекту подключиться, но чуть позже =) Как раз из-за собственных проектов
Ну… насчет Yii2 вы загнули. :) В архитектуре Yii не каждый мидл с пол пинка разберется, да и мне хотелось бы чтобы Yii писался профессионалами, а не джуниорами.
Как вариант прибиться к какой ни будь OpenSource CMS с микро-MVC фреймверком в ядре. Например, к Flexo flexo.up.dn.ua
Как вариант прибиться к какой ни будь OpenSource CMS с микро-MVC фреймверком в ядре. Например, к Flexo flexo.up.dn.ua
Хорошие предпосылки стать таки разработчиком. Несколько советов по именованию структуры проекта в части library(lib?). Наверно стоило бы называть вещи своими именами, вместо functions extend, например, вместо models bdconnect, bdconfig, bdlib, router запихнуть в конфиг. Я так думаю, что в той папке будет всегда 1 файл с роутами, так что смысл в отдельной папке для 1 файла нет наверно. Так же files в public, обычно так называют фолдер с css js файлами.
Можно положить проект на github.com и пригласить всех поучаствовать в его развитии. Думаю для начинающих было весьма кстати.
Можно положить проект на github.com и пригласить всех поучаствовать в его развитии. Думаю для начинающих было весьма кстати.
На счет названия файлов/папок это да, косяки были, хотя согласен не со всем. Зачем пихать роутер в конфиг, ecли это скрипт маршрутизации а не список маршрутов. Настройка роутера лежит в файле app/config/routes.php. На счет отдельной папки вы скорее всего правы. Далее — models. Там не будет никакой настройки соединения и т.д. Там будут отдельно вынесенные функции для работы с определенной таблицей в бд.
===
Как-то я попросил его показать мне исходники, и был не особо удивлен — если не считать некоторое количество инклудов, весь PHP состоял в расширении файлов (корзина и все прочие примочки, составлявшие «магазинную часть» были на Ecommtools тчк com).
===
Фраза «весь PHP состоял в расширении файлов» слегка вынесла мозг ) О каком расширении речь? Об extends для классов? Или о чем?
Как-то я попросил его показать мне исходники, и был не особо удивлен — если не считать некоторое количество инклудов, весь PHP состоял в расширении файлов (корзина и все прочие примочки, составлявшие «магазинную часть» были на Ecommtools тчк com).
===
Фраза «весь PHP состоял в расширении файлов» слегка вынесла мозг ) О каком расширении речь? Об extends для классов? Или о чем?
На гитхаб (или что то похожее) не хотите выложить? а то имхо как то не солидно исходники на файлообменниках хранить. Да и вам сасмому с СКВ удобнее будет работать, даже если один трудитесь.
Полностью согласен на счет гитхаба, просто не имею опыта работы с ним (стыдно что ппц), поэтому пока так
Тоже писал такие велосипеды несколько лет назад. Потом посмотрел в сторону готовых фреймворков и забил на свое рукоделие. И вам того же рекомендую.
Эм…
а разве MVC — это не паттерн ООП?
В данном случае у вас просто перенята анатомия фреймворка, пассивная модель MVC.
А в общем, хорошая работа, стране нужны статьи с велосипедами, для понимания азов.
Рекомендация — пользуйтесь GitHub
а разве MVC — это не паттерн ООП?
В данном случае у вас просто перенята анатомия фреймворка, пассивная модель MVC.
А в общем, хорошая работа, стране нужны статьи с велосипедами, для понимания азов.
Рекомендация — пользуйтесь GitHub
Скорее это архитектурный паттерн, чаще всего реализуемый с помощью ООП.
UFO just landed and posted this here
Если поехали про велосипеды, то вот мой Yii-like подобный фреймворк github.com/jmas/small_framework_like_yii сделанный в качестве тестового задания для трудоустройства.
Ну и если пришло время меряться килобайтами, то без контроллера и моделей мой 23 кб. Тем не менее он поддерживает:
* AR на прямитивном уровне Model.save()
* Инициализацию компонент из конфига
* Yii-подобный синтаксис
* Примитивные драйверы для БД (по-умолчанию используется PDO, но написан драйвер для MySQLi)
* Ну и так же валидаторы для моделей тоже есть
И сфера применения фреймверка: REST приложения.
Сам фреймворк поддерживаться и расширяться не будет (это для информации).
* AR на прямитивном уровне Model.save()
* Инициализацию компонент из конфига
* Yii-подобный синтаксис
* Примитивные драйверы для БД (по-умолчанию используется PDO, но написан драйвер для MySQLi)
* Ну и так же валидаторы для моделей тоже есть
И сфера применения фреймверка: REST приложения.
Сам фреймворк поддерживаться и расширяться не будет (это для информации).
Думаю эта информация будет полезна:
PHP: The Right Way
PHP: The Right Way
UFO just landed and posted this here
Совет: разобрать код нескольких серьезных фреймворков (Zend, Simfony, Yii).
Да, это стоит сделать. Заодно и с ООП получше разберусь, а то я пока знаком с ним только на уровне использования готовых объектов, то есть принцип понимаю, а самому сделать что-либо подобное будет затруднительно.
Кстати, Yii оказался очень доступным фреймворком для понимания. Более того: на примере зависимостей и иерархии классов в этом фреймворке я достаточно много понял для себя. Удачи!
Спасибо за указание направления) Кстати, я пытался пользоваться Yii после нескольких проектов, выполненных на Zend (мой первый фреймворк), и довольно долго вдуплял что там да как, поковырял немного и вернулся на зенд. Вот теперь будет вторая попытка, и на этот раз, так сказать, «изнутри»)
Залейте фреймворк на github:
1. можно легко посмотреть код, и дать дельные замечания, не скачивая, не устанавливая приложение, не конфигурируя сервер
2. можно добавлять комментарии к файлам, ссылаться на какой-либо код для объяснения всяких моментов
3. начните использовать гит сейчас, потому что все равно в какой то момент жизни вам придется это сделать: желаете вы этого или нет.
Посмотрите что такое Composer кстати.
1. можно легко посмотреть код, и дать дельные замечания, не скачивая, не устанавливая приложение, не конфигурируя сервер
2. можно добавлять комментарии к файлам, ссылаться на какой-либо код для объяснения всяких моментов
3. начните использовать гит сейчас, потому что все равно в какой то момент жизни вам придется это сделать: желаете вы этого или нет.
Посмотрите что такое Composer кстати.
Я считаю Yii идеалом. Zend уж очень не понравился своим огромным пузом.
Кстати, yii2 уже можно использовать, правда не рекомендуется на продакшене. Говорят, он еще «вкуснее»
Кстати, yii2 уже можно использовать, правда не рекомендуется на продакшене. Говорят, он еще «вкуснее»
Глобал и без ООП (хотя я не поклонник оверинженеринга — но всеже это за гранью добра) — фуфуфу…
Из-за того, что вместо того, чтобы контрибьютить в одинх проект, каждый php-шник пишет свой лисапед, в этом языке нет нормальных инструментов.
10 рубистов сделают одну хорошую библиотеку, а 10 php-шников сделают 10 разных не очень хороших, причем работать с ними, кроме самого автора вряд ли кто-то сможет.
10 рубистов сделают одну хорошую библиотеку, а 10 php-шников сделают 10 разных не очень хороших, причем работать с ними, кроме самого автора вряд ли кто-то сможет.
То есть вы прочитали топик, опубликованный в хабе PHP, только для того, что бы сказать, что Ruby куда лучше PHP?
Это нормально, не переживай… Утром еще пара сотен таких-же хомячков набегут, т.ч. береги нервы ;)
Зашел я в топик в хабе PHP, потому что я работаю в том числе и с PHP.
Если я работаю с PHP я должен любить и защищать PHP сообщество?
Ах да, покажите мне место, где я вообще сравнивал Ruby и PHP. (Подсказка, речь шла не о языках, а о программистах. Оба языка вполне нормальные, чтобы решать на них задачи)
Если я работаю с PHP я должен любить и защищать PHP сообщество?
Ах да, покажите мне место, где я вообще сравнивал Ruby и PHP. (Подсказка, речь шла не о языках, а о программистах. Оба языка вполне нормальные, чтобы решать на них задачи)
Нужно уметь найти хорошую библиотеку, нужно быть профи в PHP что бы утверждать, что он г… о. Хотя, можно просто потроллить огромную массу php разработчиков. Скажите мне что нельзя сделать на php, и я скажу как это делается.
Даешь код на github?
Сейчас пытаюсь запилить
Выложил: github.com/SazereS/NoNameFramework.git
Сейчас добавлю в пост
Сейчас добавлю в пост
Единственный плюс, который я вижу – полная совместимость с php версий так десятилетней почти давности. На этом они заканчиваются. Глобальные переменные, отсутствие гибкости… Вы развивать его вообще как собирались?
Нет, не собирался. Да и сложно сделать проект гибким, когда собираешь его «на коленке», да и вообще первый раз в эту степь залезаешь
Зачем тогда статья на Хабре и утверждение о том, что без ООП он лучше?
«Отсутствие ООП. Не знаю, преимущество это или наоборот минус» — видимо этой фразой я утверждал, что без ООП он лучше?
А статья на хабре ради того, что бы понять куда двигаться дальше. Просто в моем окружении (к сожалению) нет людей, которые могли бы помочь мне советом в этом плане. А выложив все это на хабр я за 30 минут получил чуть ли не руководство к действию на ближайший месяц минимум.
А статья на хабре ради того, что бы понять куда двигаться дальше. Просто в моем окружении (к сожалению) нет людей, которые могли бы помочь мне советом в этом плане. А выложив все это на хабр я за 30 минут получил чуть ли не руководство к действию на ближайший месяц минимум.
Когда дорастете: подумаете, что нужно покодить на еще паре тройке языков. Этак для понимания общего положения вещей в программировании. Потому что сейчас в голову закрадывается мысль, что скрипиовых языков нужно знать парочку, как минимум PHP+Python (я о сервреной части), что бы вобрать лучшие практики из обоих. Так же наверное RoR тоже стоит хотя бы раз развернуть и написать пробное приложение.
И если вы до сих пор работаете под Windows, то серьезно подумайте над переходом на Linux подобную систему. Потому что некоторые вещи в Linux делаются одной командой (например загрузить и развернуть вебсервер можно парой команд). Да и некоторые PHP-вещи да и не только, проще понять, когда ты работаешь в Linux.
И если вы до сих пор работаете под Windows, то серьезно подумайте над переходом на Linux подобную систему. Потому что некоторые вещи в Linux делаются одной командой (например загрузить и развернуть вебсервер можно парой команд). Да и некоторые PHP-вещи да и не только, проще понять, когда ты работаешь в Linux.
А вы перед созданием своего велосипеда вообще смотрели что есть уже в мире?
phptrends.com/category/9
Создавать своё, конечно, прикольно и правильно для собственного развития, но вот по части микрофреймворков на PHP помоему их уже достаточно на любой вкус.
phptrends.com/category/9
Создавать своё, конечно, прикольно и правильно для собственного развития, но вот по части микрофреймворков на PHP помоему их уже достаточно на любой вкус.
А мне вот интересно, почему на php понаписано столько велосипедов, фреймворков и форков фрейморков.
А на python или ruby, грубо говоря — по одному.
А на python или ruby, грубо говоря — по одному.
PHP по прежнему популярен, многие с него начинают. В данном случае количество играет важную роль.
Есть подозрение, что php фреймоврков и CMS больше чем их используется в сумме во всех проектах.
С MV(V)C в javascript похожая ситуация.
MVC стало модным… после 30 лет забвения
С MV(V)C в javascript похожая ситуация.
MVC стало модным… после 30 лет забвения
Думаю, ответ надо искать во временах PHP3, в котором не было ООП вообще, а ФП только в зародыше, и модифицировать неустраивающее поведение системы или расширить своим было сложновато без костылей, а костыли обладают свойством неуниверсальности.
Во времена php3 ещё не было ни руби на рельсах (2005), ни питона на джанге (2003).
Они появились одновременно с php5/zend (2004).
Во влияние наследственного кода 10летней давности верится с трудом.
И тем не менее, при попытке нагуглить zend cms в первых же строчках вываливается «cms с нуля». Тут явно что-то не чисто.
Они появились одновременно с php5/zend (2004).
Во влияние наследственного кода 10летней давности верится с трудом.
И тем не менее, при попытке нагуглить zend cms в первых же строчках вываливается «cms с нуля». Тут явно что-то не чисто.
Не столько сам код виноват, сколько практики его разработки и поддержки, по-моему. Уже выработался стереотип «если что-то нестандартное нужно, то проще сделать свое специализированное, чем адаптировать чужое якобы универсальное». Плюс такие мелочи, как распространенность дешевых (или вообще бесплатных) хостингов под php только с ftp доступом, означающая невозможность использовать менеджеры пакетов (пускай даже такой как убогий по мнению многих как pear) и кодогенерацию.
Могу ошибаться, но успешные PHP-разработчики давно взяли себе на вооружение и chef, и capistrano. PHP-хостинги с фтп вырождающееся явление: снимают остаточные сливки на ажиотаже вокруг кажущейся простоты разработки. Прогресс не стоит на месте, не смотря на то, что в некоторых ведущих вузах кроме php и asp ничего не читают. Тем более в нынешнем php можно сделать все, что угодно, под любой production. Вынужден это признать, при всей моей негативной предвзятости к php.
Другими словами, когда сообщество перешло на «паттернизированный» подход к разработке, стало проще выделить те особенности которыми php силен, и решать задачи, не свойственные php, в рамках одного проекта, универсальными решениями на других языках. При наличии API, либо удобного DSL — не сложно.
Другими словами, когда сообщество перешло на «паттернизированный» подход к разработке, стало проще выделить те особенности которыми php силен, и решать задачи, не свойственные php, в рамках одного проекта, универсальными решениями на других языках. При наличии API, либо удобного DSL — не сложно.
В PHP традиционно сильна ниша «коробочных» или «заказных одноразовых» продуктов, предназначенных для так называемых веб-мастеров, которые zip-архив развернуть и залить по ftp могут, но чему-то большему учиться просто не хотят. Вообще сообщество довольно фрагментировано и решений и по потребностям, и по «способностям», устраивающих всех просто нет.
но по идее ООП-приложения съедают гораздо больше ресурсов, чем приложения, написанные в процедурном стиле.
Когда используешь базу данных, данное высказывание теряет смысл, зато удобнее работать с ООП, чем с функциями
<?php if($_view['books']) foreach ($_view['books'] as $v) { ?>
#<?=$v['id'] ?>: <a href="<?=baseUrl('books/view/id/'.$v['id']) ?>"><?=$v['title'] ?></a><br />
<?php } ?>
Есть немного другой синтаксис, выглядит он так:
<?php if($_view['books']) foreach ($_view['books'] as $v) : ?>
#<?=$v['id'] ?>: <a href="<?=baseUrl('books/view/id/'.$v['id']) ?>"><?=$v['title'] ?></a><br />
<?php endforeach;?>
Мне кажется такой синтаксис более приятен в шаблонах.
Так же для рендеринга шаблона рекомендую следующую функцию:
function render($template_path, $vars){
extract($vars, EXTR_OVERWRITE);
ob_start();
include($template_path);
$content = ob_get_contents();
ob_end_clean();
return $content;
}
Думаю, полезнее будет немного помучать документацию, чем читать мои комментарии к этой функции.
Про такой синтаксис я знаю, просто мне он немного непривычен. Да и у каждого свои предпочтения =)
А вот за ob_start() большое спасибо, не знал, буду использовать.
А вот за ob_start() большое спасибо, не знал, буду использовать.
а еще можно в место
просто
ob_get_clean() на php.net
$content = ob_get_contents();
ob_end_clean();
return $content;
просто
return ob_get_clean();
ob_get_clean() на php.net
Угу, ещё одна из вещей в PHP из разряда «это невозможно понять, это нужно запомнить». А на русском ещё и ошибка в переводе bugs.php.net/bug.php?id=64835. усугубляющая непонимание.
Мне кажется, что разница clear & delete при написании кода существенно не отличается в плане конечного результата.
ИМХО, могу ошибаться, удаление буфера, уменьшает расход оперативки, не? О_о
Это вопрос с так сказать предположением, по этому не пинайте сильно неуча
ИМХО, могу ошибаться, удаление буфера, уменьшает расход оперативки, не? О_о
Это вопрос с так сказать предположением, по этому не пинайте сильно неуча
Проблема в том, что есть функция ob_clean() которая очищает буфер, но его не удаляет, он продолжает перехватывать вывод в тот же буфер (буферы могут быть вложены друг в друга на несколько уровней), то есть используется если нужно предыдущий вывод отменить и начать новый, а есть ob_end_clean(), которая именно что удаляет, понижая уровень или (если первый был) переставая перехватывать вывод (а очистка — побочный эффект по сути) и используется, если нужно предыдущий отменить, но новый выводить уже без буфера (или в буфер уровнем меньше того, что был). ob_get_clean() это же по сути ob_get_contents_and_end_clean(), но не ob_get_contents_and_clean(); как можно было бы подумать из названия или ошибочного русского перевода.
Первая же кавычка вам всё сломает.
Будет очень не приятно, когда в разных моделях у вас будут одинаковые методы.
books.php
comments.php
Понятно, что можно описать стандарт именования функция для вашего фреймворка, но все же присмотритесь к способу сделать так
books.php
function getAllByDate(){}
comments.php
function getAllByDate(){}
loadModel('books');
loadModel('comments');
$all_books = getAllByDate();
Понятно, что можно описать стандарт именования функция для вашего фреймворка, но все же присмотритесь к способу сделать так
$books->getAllByDate();
$comments->getAllByDate();
<?php // Подключаем модель models/books.php loadModel('books'); // Проверяем, пришли ли данные методом POST <?php // Подключаем модель models/books.php loadModel('books'); // Проверяем, пришли ли данные методом POST
я тоже писал MVC-фреймворк
А мне понравилось :-) напомнило меня лет эдак 7 назад.
// Загружаем лайаут loadLayout($_response['layout']);
// Загружаем лайаут с помощью функции loadLayout
// в качестве параметра передаем переменную $_response которая является массивом и содержит ключ 'layout'
loadLayout($_response['layout']);
Надеюсь намек понятен :)
Вы все еще комментируете фразы которые, можно перевести на русский язык без словаря? Тогда мы идем к вам!
// Загружаем лайаут loadLayout($_response['layout']);
Скорее так :)
loadLayout($_response['layout']);Ну об этом и речь — во всех примерах кода в посте огромное количество коментариев и большинство из них избыточны.
На мой взгляд такие коментарии просто засоряют код т.к. никакой пользы от них нет и со временем если их не обновлять они могут только запутать.
Гораздо лучше иметь чистый код чем запутанный и непонятный с кучей устаревших коментариев.
На мой взгляд такие коментарии просто засоряют код т.к. никакой пользы от них нет и со временем если их не обновлять они могут только запутать.
Гораздо лучше иметь чистый код чем запутанный и непонятный с кучей устаревших коментариев.
Мне кажется, что каждый программист сначала пытается написать свой собственный фреймворк, после чего уже начинает использовать готовые фреймворки :-)
Скорее сначала пытается использовать готовые (коль скоро слово «фреймворк» знает), считает их тяжелыми, громоздкими, неэффективными, начинает писать свой и приходит к ещё худшему результату…
И такое есть :)
потом он делает высоконагруженные приложения на фреймворках, контрибьютит пару багов и, вдруг, если, О Чудо!, компания почему-то хочет сделать исключительно проприетарное ПО, ему правда выделяют время и средства на написание полноценного фреймворка и он пишет то к чему разные Симфони в коробке приходят лишь через пару major-версий.
Это как извечный цыганский вопрос о детях: этих отмыть или новых наделать!
Это как извечный цыганский вопрос о детях: этих отмыть или новых наделать!
Может, среди всех комментариев эти мысли уже прозвучала.
ООП в вашем случае дает больше преимуществ, чем недостатков (элементарный пример хорошего применение — создание абстрактного класса для моделей и контроллеров, в которых будет концентрироваться общая для них всех логика, а конкретные реализации будут создаваться наследованием. То же верно для абстракции от СУБД, чтобы потом было удобно создавать реализации не только на MySQL). Еще было бы неплохо как-то автоматизировать процесс создания табличек, а не писать create table вручную. Если хранить структуру таблиц, например, в каком-то специальном массиве, можно сделать более удобным CRUD с автоматическим соединением таблиц и выделением и удалением связанных объектов.
Еще можно сделать какое-то API для расширяемости, которое позволило бы вмешиваться в процессы и изменять их входные/выходные данные, а так же добавлять новые функции.
Я сам на данный момент пишу похожий «велосипед», но у меня немного другие цели.
ООП в вашем случае дает больше преимуществ, чем недостатков (элементарный пример хорошего применение — создание абстрактного класса для моделей и контроллеров, в которых будет концентрироваться общая для них всех логика, а конкретные реализации будут создаваться наследованием. То же верно для абстракции от СУБД, чтобы потом было удобно создавать реализации не только на MySQL). Еще было бы неплохо как-то автоматизировать процесс создания табличек, а не писать create table вручную. Если хранить структуру таблиц, например, в каком-то специальном массиве, можно сделать более удобным CRUD с автоматическим соединением таблиц и выделением и удалением связанных объектов.
Еще можно сделать какое-то API для расширяемости, которое позволило бы вмешиваться в процессы и изменять их входные/выходные данные, а так же добавлять новые функции.
Я сам на данный момент пишу похожий «велосипед», но у меня немного другие цели.
Возможно с ООП и было бы гораздо лучше, но создавался этот фреймворк изначально для того, что бы человек понял как делать хоть сколько-нибудь динамические сайты. Он об ООП и не слышал, так что пришлось все делать вот так, «велосипедно». В другом случае я бы естественно попытался использовать классы, возможно даже попробовать что-нибудь в АОП-стиле замутить. Но в этом конкретном случае такой возможности не было.
По личному (в роли типа учителя) опыту внезапно оказалось, что ООП более понятен «обычным» людям, чем процедурное программирование. Как-то плохо люди воспринимают концепцию переменной, а вот концепцию свойства объекта — хорошо. Хотя на многих примерах разница почти только синтаксическая ("_" вместо "->"). Единственное, слово «метод» нужно вводить аккуратно, лучше классическое «сообщение», а то и вообще «воздействие».
Sign up to leave a comment.
NoName Framework или Как я велосипед изобретал