В новой Alto выделен специальный уровень конфига — уровень темы, а сама тема еще к новой структуре не адаптирована.
Что бы тема слушалась свои конфиги — их нужно получать на уровне темы, то есть, на Вашем примере, в файле common/templates/skin/synio/header.tpl нужно так:
И еще при регистрации логин формировать автоматически как хэш емэйла. Тогда получится, что логин есть и он уникальный, как если бы пользователь придумывал его сам.
Голый энтузиазм быстро проходит. Но бесплатные и opensorce-проекты тоже могут окупаться, иметь авторитет и конкурентоспособность, например jQuery а также очень много и много проектов…
Согласен с leginnn — документация должна быть функциональной и если делать отдельный блог, то лучше сразу определить формат размещаемых топиков:
1. Например в виде подробного мануала по части функционала.
На примере кэширования, я думаю, разработчикам, осваивающим Alto будут интересны, как минимум, следующие вопросы:
— Типовые способы установки и чтения кэша (ведь практически везде используется код if (false === ($data = ..., но что бы до этого дойти нужно перелопатить кучу кода);
— Что вообще нужно кэшировать, а что нет;
— Как формировать имя ключа кэша;
— Как формировать имя тега и как их, теги, использовать (ведь тегирование в кэше используется для удаления групп данных из кэша, как средство поддержания его актуальности и должны отражать условие очистки (imho), например, как в Alto и сделано в тегах: «topic_update» — очищаем при апдейте топика, «blog_new» — очищаем при добавлении блога...)
— Какое время жизни тега устанавливать — день, два, неделю (зависит же от способа использования кэша и в одних случаях можно просто установить достаточно большое время потому что кэш обновляется принудительно, а без обновления он будет вечно актуальным. В других же случаях время жизни кэша строго определено)
— Что за кэш «tmp» (Очень соблазнительно его использовать как суперглобальную область — у меня получилось передать в этот тип кэша данные из модуля, а потом вывести их напрямую из шаблона SMARTY, но должно быть понятно, что это средство оптимизации и используется только с этой целью)
— Семантика функций (для полноты картины)
— Дополнительные материалы (например dklab.ru/chicken/nablas/48.html)
Я к чему это все. Перечень вопросов, указанных выше можно освятить и в блоге «Alto CMS inside — как это устроено и работает», если и делать новый блог, то нужно определить:
— требования к уровню топика — читать же будут люди достаточно понимающие,
— требования к подаче материала — топик достаточно полно должен описывать проблему — при таком подходе что бы описать функционал Alto потребуется конечное количество топиков, что будет показателем покрытия функционала техническим описанием.
2. Можно определить структуру топиков как cookbook — описание типовых подходов к решению задач — очень и очень полезная штука.
Ну, это, собственно, первое и второе, что в голову пришло )
Нет, иную реализацию я не предлагаю. Цель плагина не вносить новое, а упростить написание кода используя предложенные в плагине механизмы.
Что касается валидаторов в LS, то у меня к ним неоднозначное отношение:
1. С одной стороны это качественный механизм проверки, который в частности используется и в сущности User
2. А с другой стороны 15 классов и 1500+ строк кода, что бы использовать их в 5-и сущностях из более 7 десятков, причем валидация значений с их помощью вообще не используется. В отличие от Yii, использование валидаторов при проверке модели/сущности не является обязательным – отсюда и нежелание разработчиков их использовать – зачем учить/рассматривать код 15 классов и методику их использования, если можно написать свой метод validateMe() и его пользовать – быстрее и проще. Получается, что это архитектурный излишек, без которого можно и обойтись, причем его использование не доставляет очевидных плюсов.
3. А может, валидаторы LS – это задел на будущее – потом, планируется что-то большое и удобное с их использованием.
Цель, которую я ставил при реализации предложенного набора валидаторов проста, и на самом деле единственна – валидация набора значений для того, что бы сократить объем кода и сделать его читабельней. Я не покушался на механизм модуля Validate и как-то менять его не предлагаю.
Вот пример я взял код из модуля Admin и в нем сделал все проверки через вализаторы. Сразу скажу – пример не рабочий, поскольку не все используемые валидаторы и их модификаторы реализованы.
Плюсы-минусы: в бою валидаторы не обкатывались, поэтому сложно судить. Наверное, примеры будут позже.
Я не писал документ с нуля и придумывать что-то новое и оригинальное смысла не вижу, да и не получиться. Да в документе нет ссылок на то, откуда, из каких рекомендаций, взят горбатый регистр или использование/неиспользование префиксов и т.д., но если это принципиально, то я могу сказать что предложные принципы именования были определены исходя из:
— анализа кода CMS Livestreet,
— анализа кода Alto,
— кода фреймворка Yii (как пример кода, где не используется венгерская нотация),
— API Windows (как пример использования венгерской нотации),
— стандарта кодирования Zend,
— стандартов PSR,
— материалов интернет — в частности habrahabr.ru/post/38214/,
— книги «Совершенный код» Стива Макконнелла
— опыта собственной практики.
Предложение я сделал для того, что бы внести некоторую определенность в структуру кода, поскольку видно (если вчитаться в код) что какие-то правила и соглашения авторы CMS и плагинов используют, но они, эти соглашения, нигде не зафиксированы.
Я делал пометки для себя, но когда они оформились в некоторую структуру, я выделил основные закономерности в коде, а пробелы дополнил из выше указанного списка.
Заметьте, я предложил только систему именования — даже не предложил. а сформулировал уже существующий, сложившийся порядок, например документ variables.txt:
— В общих положениях сформулирован принцип венгерской нотации, по которой нет четких требований так как это не стандарт, а подход.
— Префиксы — анализ кода Alto и LS выдал их список (Да я открывал код каждого модуля, маппера и сущности, читал этот код и встречающиеся префиксы выписывал на бумагу). Могу сказать, что других префиксов в этих CMS нет.
— Суффиксы-Исключения определены по тому же принципу.
Вопрос? Что именно из этого документа мне привязать к какому стандарту.
Если подытожить вышесказанное документ variables.txt представляет собой сформулированный принцип венгерской нотации для CMS Alto.
В последнем документе classes.txt используются выдержки ZEND+PSR, но тут тоже вопрос? константа большими буквами пишется и в С++ то требование пошло от него.
В итоге: Да я согласен с Вами источник должен быть упомянут — я сделал это в комментарии, добавлю и на гитхаб.
Да, вернет. Каждый элемент цепочки является фактическим объектом, а не фантомом. Этот плюс не увидел.
Хотелось бы указать, что минусы тоже есть, например маппер (и вообще все наследники LsObject) получают возможность обращаться к модулям — ломается архитектура, но это все объигрывается…
Вопрос по поводу разделения маппера по таблицам снимается.
Свел использование таблиц мапперами в такую сетку:
Видно, что маппер действительно жестко не привязан к какой-либо таблице.
С пунктом 2 согласен, с пунктом 1 нет.
Я постараюсь в ближайшее время перевести один из плагинов в нотацию, которую я предлагаю, а там — по коду можно будет обсудить более предметно.
Кроме БД я других источников в LS/Alto не видел — мы говорим применительно к этой LS.
В силу будущего масштабирования вопрос разделения маппера по источнику данных, думаю, сам встанет.
Да, маппер не работает с таблицей,маппер получает данные одному ему лищь ведомым способом — и другим объектам даже не нужно знать как и откуда они получены, но я ниже написал, что маппер дает данные и сущности и модулю — а это разного сорта данные.
Пока не готов продолжать обсуждение. Нужно подумать.
Просто для PhpStorm есть плагин LS, который доставляет автокомплит по магическим методам, но Заглавные и строчные он различает, поэтому я для себя определил, что с маленьких только геттеры/сеттеры.
С другой стороны геттеры и сеттеры — особый вид методов и обособленная нотация для них смотреться как-то отличительно не будет.
Я сам привык начинать имена (как методов, так и переменных) с маленькой буквы — и еще раз скажу — позиция моя здесь не принципиальна.
Да, сущность ни в коем разе не является эквивалентом записи, но тут есть такая двойственность логики: Сущность получается ядром CMS от массива данных
$aTalks[]=Engine::GetEntity('Talk',$aRow);
Ровно также сущность может быть получена от любого массива, но по факту используется от записи таблицы!
В отношении сущности маппер — конструктор сущности.
В отношении модуля маппер — поставщик данных.
При разделении маппера по таблицам можно конкретизировать поставщика данных для модeля ($mUser, mBlogUser) и поставить однозначное соответствие сущности.
Я согласен, что сам маппер, по сущности своей, просто средство связи между БД и другими объектами — какими бы они не были, но так как маппер работает с таблицей, то, на мой взгляд, удобнее было бы разделить код. Это бы уменьшило объем кода в мапперах (и увеличило количество фалов), но сделало бы архитектуру более прозрачной.
Сама венгерская нотация подразумевает определение префиксов типов конкретной среды (префиксов как типов данных, так и пользовательских типов данных), поэтому мешанины не будет — будет своя нотация не для PHP вообще (а ее и нет), а нотация для Alto.
Нет, у сущности могут быть приватные методы, начинающиеся со знака подчеркивания и публичные, например метод валидации сущности, я предлагаю начинать с LowerCase, только геттеры и сеттеры, а остальное, только через Зглавную. Например:
Получается, что у каждого модуля может быть куча сущностей, но все они пользуют один маппер. Нужно определиться — маппер своим функционалом обеспечивает сущность или модуль. Если модуль, то почему маппер представляет собой свойство модуля, как доп. объект, а не является частью его функционала напрямую через методы?
Вводя требование mapper-таблица я могу объяснить:
— принципиальную возможность многих мапперов;
— отдельную папку для одного-единственного файла маппера;
— префикс m — как тип свойства (свойств с этим типов может быть моного).
Если маппер обеспечивает модуль — нет вопросов.
Если маппер обеспечивает сущность — нужно делить.
Что бы тема слушалась свои конфиги — их нужно получать на уровне темы, то есть, на Вашем примере, в файле common/templates/skin/synio/header.tpl нужно так:
<code>... {else} <style> #container { width: {Config::Get('view.grid.fixed_width', null, Config::LEVEL_SKIN)}px; } </style> {/if} </code>а не просто {Config::Get('view.grid.fixed_width')}Также, в новой версии доработана функция смарти cfg и можно использовать ее так:
<code>... {else} <style> #container { width: {cfg name="view.grid.fixed_width" level=Config::LEVEL_SKIN}px; } </style> {/if} </code>1. Например в виде подробного мануала по части функционала.
На примере кэширования, я думаю, разработчикам, осваивающим Alto будут интересны, как минимум, следующие вопросы:
— Типовые способы установки и чтения кэша (ведь практически везде используется код if (false === ($data = ..., но что бы до этого дойти нужно перелопатить кучу кода);
— Что вообще нужно кэшировать, а что нет;
— Как формировать имя ключа кэша;
— Как формировать имя тега и как их, теги, использовать (ведь тегирование в кэше используется для удаления групп данных из кэша, как средство поддержания его актуальности и должны отражать условие очистки (imho), например, как в Alto и сделано в тегах: «topic_update» — очищаем при апдейте топика, «blog_new» — очищаем при добавлении блога...)
— Какое время жизни тега устанавливать — день, два, неделю (зависит же от способа использования кэша и в одних случаях можно просто установить достаточно большое время потому что кэш обновляется принудительно, а без обновления он будет вечно актуальным. В других же случаях время жизни кэша строго определено)
— Что за кэш «tmp» (Очень соблазнительно его использовать как суперглобальную область — у меня получилось передать в этот тип кэша данные из модуля, а потом вывести их напрямую из шаблона SMARTY, но должно быть понятно, что это средство оптимизации и используется только с этой целью)
— Семантика функций (для полноты картины)
— Дополнительные материалы (например dklab.ru/chicken/nablas/48.html)
Я к чему это все. Перечень вопросов, указанных выше можно освятить и в блоге «Alto CMS inside — как это устроено и работает», если и делать новый блог, то нужно определить:
— требования к уровню топика — читать же будут люди достаточно понимающие,
— требования к подаче материала — топик достаточно полно должен описывать проблему — при таком подходе что бы описать функционал Alto потребуется конечное количество топиков, что будет показателем покрытия функционала техническим описанием.
2. Можно определить структуру топиков как cookbook — описание типовых подходов к решению задач — очень и очень полезная штука.
Ну, это, собственно, первое и второе, что в голову пришло )
Alyona спасибо за идею. Будет время допилю до рабочего варианта.
Любой из них можно прикрутить к Alto, но в чем будет бонус?
Плюс к этому, большинство этой красоты работает только с современными браузерами, так, что тут дело сугубо индивидуальное. — Мое мнение.
Что касается валидаторов в LS, то у меня к ним неоднозначное отношение:
1. С одной стороны это качественный механизм проверки, который в частности используется и в сущности User
2. А с другой стороны 15 классов и 1500+ строк кода, что бы использовать их в 5-и сущностях из более 7 десятков, причем валидация значений с их помощью вообще не используется. В отличие от Yii, использование валидаторов при проверке модели/сущности не является обязательным – отсюда и нежелание разработчиков их использовать – зачем учить/рассматривать код 15 классов и методику их использования, если можно написать свой метод validateMe() и его пользовать – быстрее и проще. Получается, что это архитектурный излишек, без которого можно и обойтись, причем его использование не доставляет очевидных плюсов.
3. А может, валидаторы LS – это задел на будущее – потом, планируется что-то большое и удобное с их использованием.
Цель, которую я ставил при реализации предложенного набора валидаторов проста, и на самом деле единственна – валидация набора значений для того, что бы сократить объем кода и сделать его читабельней. Я не покушался на механизм модуля Validate и как-то менять его не предлагаю.
Вот пример я взял код из модуля Admin и в нем сделал все проверки через вализаторы. Сразу скажу – пример не рабочий, поскольку не все используемые валидаторы и их модификаторы реализованы.
Плюсы-минусы: в бою валидаторы не обкатывались, поэтому сложно судить. Наверное, примеры будут позже.
2. напишу позже, с телефона не удобно :)
— анализа кода CMS Livestreet,
— анализа кода Alto,
— кода фреймворка Yii (как пример кода, где не используется венгерская нотация),
— API Windows (как пример использования венгерской нотации),
— стандарта кодирования Zend,
— стандартов PSR,
— материалов интернет — в частности habrahabr.ru/post/38214/,
— книги «Совершенный код» Стива Макконнелла
— опыта собственной практики.
Предложение я сделал для того, что бы внести некоторую определенность в структуру кода, поскольку видно (если вчитаться в код) что какие-то правила и соглашения авторы CMS и плагинов используют, но они, эти соглашения, нигде не зафиксированы.
Я делал пометки для себя, но когда они оформились в некоторую структуру, я выделил основные закономерности в коде, а пробелы дополнил из выше указанного списка.
Заметьте, я предложил только систему именования — даже не предложил. а сформулировал уже существующий, сложившийся порядок, например документ variables.txt:
— В общих положениях сформулирован принцип венгерской нотации, по которой нет четких требований так как это не стандарт, а подход.
— Префиксы — анализ кода Alto и LS выдал их список (Да я открывал код каждого модуля, маппера и сущности, читал этот код и встречающиеся префиксы выписывал на бумагу). Могу сказать, что других префиксов в этих CMS нет.
— Суффиксы-Исключения определены по тому же принципу.
Вопрос? Что именно из этого документа мне привязать к какому стандарту.
Если подытожить вышесказанное документ variables.txt представляет собой сформулированный принцип венгерской нотации для CMS Alto.
Тоже самое можно сказать и про документ db
В последнем документе classes.txt используются выдержки ZEND+PSR, но тут тоже вопрос? константа большими буквами пишется и в С++ то требование пошло от него.
В итоге: Да я согласен с Вами источник должен быть упомянут — я сделал это в комментарии, добавлю и на гитхаб.
Так получается очень естественно и более понятно. Полностью согласен. попробую реализовать так.
Про наследников — это я с LS спутал. Там LsObject не содержит __call метода.
Хотелось бы указать, что минусы тоже есть, например маппер (и вообще все наследники LsObject) получают возможность обращаться к модулям — ломается архитектура, но это все объигрывается…
Свел использование таблиц мапперами в такую сетку:
Видно, что маппер действительно жестко не привязан к какой-либо таблице.
Я постараюсь в ближайшее время перевести один из плагинов в нотацию, которую я предлагаю, а там — по коду можно будет обсудить более предметно.
В силу будущего масштабирования вопрос разделения маппера по источнику данных, думаю, сам встанет.
Да, маппер не работает с таблицей,маппер получает данные одному ему лищь ведомым способом — и другим объектам даже не нужно знать как и откуда они получены, но я ниже написал, что маппер дает данные и сущности и модулю — а это разного сорта данные.
Пока не готов продолжать обсуждение. Нужно подумать.
Просто для PhpStorm есть плагин LS, который доставляет автокомплит по магическим методам, но Заглавные и строчные он различает, поэтому я для себя определил, что с маленьких только геттеры/сеттеры.
С другой стороны геттеры и сеттеры — особый вид методов и обособленная нотация для них смотреться как-то отличительно не будет.
Я сам привык начинать имена (как методов, так и переменных) с маленькой буквы — и еще раз скажу — позиция моя здесь не принципиальна.
Ровно также сущность может быть получена от любого массива, но по факту используется от записи таблицы!
В отношении сущности маппер — конструктор сущности.
В отношении модуля маппер — поставщик данных.
При разделении маппера по таблицам можно конкретизировать поставщика данных для модeля ($mUser, mBlogUser) и поставить однозначное соответствие сущности.
Я согласен, что сам маппер, по сущности своей, просто средство связи между БД и другими объектами — какими бы они не были, но так как маппер работает с таблицей, то, на мой взгляд, удобнее было бы разделить код. Это бы уменьшило объем кода в мапперах (и увеличило количество фалов), но сделало бы архитектуру более прозрачной.
но
Вводя требование mapper-таблица я могу объяснить:
— принципиальную возможность многих мапперов;
— отдельную папку для одного-единственного файла маппера;
— префикс m — как тип свойства (свойств с этим типов может быть моного).
Если маппер обеспечивает модуль — нет вопросов.
Если маппер обеспечивает сущность — нужно делить.