Comments 11
1. Через нижнее подчеркивание обычно защищенные методы класса называют, а не публичные.
2. Для коробочных модулей как-то странно выглядит пункт
3. У вас на View это глобальный модуль, доступный всем частям приложения, именнованные куски тоже доступны всем получается. Все о всех знают, это не есть хорошо.
4. Возьмите за основу Symfony\Component\HttpFoundation. Используйте их request и response. Вместо того, чтобы прямо в коде header писать сразу.
2. Для коробочных модулей как-то странно выглядит пункт
И в основном шаблонном представлении добавим {{module.habr }}
3. У вас на View это глобальный модуль, доступный всем частям приложения, именнованные куски тоже доступны всем получается. Все о всех знают, это не есть хорошо.
4. Возьмите за основу Symfony\Component\HttpFoundation. Используйте их request и response. Вместо того, чтобы прямо в коде header писать сразу.
По 1 пункту — было принято такое решение (подчеркивание) чтобы выделить данные методы как системные и исключить возможность их случайного переименования или использования по незнанию. По 2 пункту — раньше были шаблонные позиции (типа left/bottom/header/right/side) но от такой практики решил отказаться, ибо выглядело это еще более странно и результат обработки не всегда был ожидаемым и да, для стандартных модулей переменные предопределены в шаблоне (который был написан выше выходит за их рамки). Не совсем понял о чем говориться в 3 и 4 пункте, да и в header я пишу только в 1 методе (void redirect($uri)).
Неужели синглтон настолько важен для каждого класса, что чуть ли не все классы от него наследуются? Хотелось бы, что бы хоть разок и дргие паттерны звучали.
да и в header я пишу только в 1 методе (void redirect($uri)).
github.com/zenn1989/ffcms/blob/9a08544e34955a420fdb36c9288f7dd74bad1a5e/load.php
zenn, заранее извини за грубую критику.
Судя по твоему коду, ты понятия не имеешь, что бывают помимо getInstance, другие статические методы и боюсь как бы для тебя и сам Singleton не казался магией (т.к. он присутсвует в каждом классе), и у тебя в коде нет ни одного Абстрактного класса, от которых, как минимум, можно было бы наследовать все компоненты, хуки и что там еще есть в системе и который помог бы разработчику узнать об обязательных методах, которые должны реализовывать компоненты.
Бегло взглянув на код классов в папке engine, я ужаснулся тому, что все классы наследуют singleton (Хорошо еще сам класс не наследует), независимо от того нужен он там или нет. Поверю, что он нужен везде, если обоснуешь его необходимость хотя бы в этом классе и почему его методы просто ни сделать статическими, как и сам параметр $metadata.
Ну и вопрос на засыпку, как использовать один и тот же модуль несколько раз на странице с разными настройками (Например в одном блоке вывести 10 новостей, в другом 5)?
Очень рекомендую пройтись по каждой ссылке на этой странице: php.net/manual/ru/language.oop5.php и ты узнаешь для себя много нового, и предвещаю через некоторое время появление магических методов, например, замена методов init на __construct
Советую также изучить литературу по теме, например, книгу PHP. Объекты, шаблоны и методики программирования, в которой представлены разные паттерны, после которой предвещаю глубокий рефакторинг кода и выход версии 6.х.х и появление MVC или HMVC ну или того, что сейчас модно.
P.S. Понимание и использование различных паттернов это очень круто, именно это доставляет удовольствие от программирования. Удачи в разработке.
Судя по твоему коду, ты понятия не имеешь, что бывают помимо getInstance, другие статические методы и боюсь как бы для тебя и сам Singleton не казался магией (т.к. он присутсвует в каждом классе), и у тебя в коде нет ни одного Абстрактного класса, от которых, как минимум, можно было бы наследовать все компоненты, хуки и что там еще есть в системе и который помог бы разработчику узнать об обязательных методах, которые должны реализовывать компоненты.
Бегло взглянув на код классов в папке engine, я ужаснулся тому, что все классы наследуют singleton (Хорошо еще сам класс не наследует), независимо от того нужен он там или нет. Поверю, что он нужен везде, если обоснуешь его необходимость хотя бы в этом классе и почему его методы просто ни сделать статическими, как и сам параметр $metadata.
Ну и вопрос на засыпку, как использовать один и тот же модуль несколько раз на странице с разными настройками (Например в одном блоке вывести 10 новостей, в другом 5)?
Очень рекомендую пройтись по каждой ссылке на этой странице: php.net/manual/ru/language.oop5.php и ты узнаешь для себя много нового, и предвещаю через некоторое время появление магических методов, например, замена методов init на __construct
Советую также изучить литературу по теме, например, книгу PHP. Объекты, шаблоны и методики программирования, в которой представлены разные паттерны, после которой предвещаю глубокий рефакторинг кода и выход версии 6.х.х и появление MVC или HMVC ну или того, что сейчас модно.
P.S. Понимание и использование различных паттернов это очень круто, именно это доставляет удовольствие от программирования. Удачи в разработке.
Извините, но почему singleton должен казаться магией? Да, возможно его использование действительно избыточно для некоторых системных логик типа meta, database и property(тут бы скорей подошел factory).
По поводу повторного использования — да, вы правы, нужно предусматривать это в параметрах метода или конструкторе класса. Так же раньше было наследование интерфейсов для моделей расширений (как вы и говорили чтобы дать разработчику понять какие методы являются обязательными) но я их упразднил до переработки и как получилось — попросту забыл о них.
Спасибо за ссылки и советы по делу, обязательно прочту ну и думаю что к новой версии я учту ваши рекомендации как и тех, кто высказывался за стандарт PSR.
По поводу повторного использования — да, вы правы, нужно предусматривать это в параметрах метода или конструкторе класса. Так же раньше было наследование интерфейсов для моделей расширений (как вы и говорили чтобы дать разработчику понять какие методы являются обязательными) но я их упразднил до переработки и как получилось — попросту забыл о них.
Спасибо за ссылки и советы по делу, обязательно прочту ну и думаю что к новой версии я учту ваши рекомендации как и тех, кто высказывался за стандарт PSR.
Причем здесь factory или PSR?
Почему нельзя вместо Meta::getInstance()->add(...) объявить метод add ститеческим и вызывать просто Meta::add(....) и так же Meta::init(), вместо Meta::getInstance()->init()? Зачем надо создавать объект класса, если то, что он делает не требует наличие этого объекта?
Еще раз повторюсь, срочно прочитай хотя бы книгу, которую я указал по ссылке, новичку в ООП она поможет открыть глаза на многие вещи. Ты забудешь про этот синглтон, ну или хотя бы поймешь в каком случае его необходимо использовать, ну и тоже самое с фабрикой, ты поймешь в чем их отличие. Прочитай что такое статический метод и статический параметр. Все это настолько просто для понимания, что через пару тройку месяцев при взгляде на свой старый код ты будешь смеяться, в прочем как и все над своим старым кодом.
Почему нельзя вместо Meta::getInstance()->add(...) объявить метод add ститеческим и вызывать просто Meta::add(....) и так же Meta::init(), вместо Meta::getInstance()->init()? Зачем надо создавать объект класса, если то, что он делает не требует наличие этого объекта?
Еще раз повторюсь, срочно прочитай хотя бы книгу, которую я указал по ссылке, новичку в ООП она поможет открыть глаза на многие вещи. Ты забудешь про этот синглтон, ну или хотя бы поймешь в каком случае его необходимо использовать, ну и тоже самое с фабрикой, ты поймешь в чем их отличие. Прочитай что такое статический метод и статический параметр. Все это настолько просто для понимания, что через пару тройку месяцев при взгляде на свой старый код ты будешь смеяться, в прочем как и все над своим старым кодом.
Это здорово, что вы развиваете систему, но зачем изначально писать код уровня Joomla?
Посмотрите, как сделана Symfony и делайте также. А еще лучше возьмите ее за основу.
Посмотрите, как сделана Symfony и делайте также. А еще лучше возьмите ее за основу.
Знаете, у Joomla (у ядра именно) уровень повыше будет. Что до Symfony — я вот никогда не понимал почему люди не хотят поставить во главу угла Dependency Injection для их самопальных CMS. CompilePass-сами можно управлять расширениями разных типов, можно все очень гибко разруливать а главное меньше говнокода… Видимо для некоторых этот подход чересчур сложный.
Sign up to leave a comment.
Разбираемся с каркасом расширений для FFCMS — hello world!