В админке «Настройки сайта / Ссылки» в параметре «Показывать на главной» задается «Домашняя страница». В папке скина создается папка /actions/ActionHomepage/ куда кладется файл index.tpl, который инклудит другой шаблон, в зависимости от того, авторизован юзер или нет.
Меня, как разработчика, всегда слегка напрягало, что у движка, под который я пишу плагины, и на котором делаю сайты для людей, как-то «внезапно» выходит новая версия, где круто все меняется. Иногда это приводило к тому, что месяц-другой работу улетал псу под хвост, потому что срочно приходилось все переделывать.
Я знаю, что на Альто начинают делать серьезные проекты, писать нехилые плагины. Поэтому этот релиз — это, своего рода, анонс, который рассказывает не только о том, ЧТО нового будет в новой версии, но и КАК это будет реализовано, чтобы сторонние разработчики могли уже сейчас планировать, как можно будет использовать новые возможности движка в своих будущих разработках.
А вообще будет возможность под определенный тип блогов создавать соответствующий шаблон .tpl?
Будет возможность задавать шаблон под тип контента. А тип контента можно привязать к типу блога. На мой взгляд, это более логичный подход, т.к. блог — это не единица контента, и не какое-то свойство, это своего рода группировка контента. Поэтому у него не может быть своего шаблона.
Либо писать свой обработчик на jQuery, который будет добавлять атрибут, либо вешать хук на сохранение топика, который будет парсить текст и добавлять атрибут
Только явно указав этот атрибут в ссылке непосредственно в шаблоне (обычно это topic_topic.tpl). Но вообще хороший вопрос, надо бы сделать, чтоб в параметрах указывать в админке при создании ссылки
Если спроецировать на наши реалии, то, возможен такой вариант:
E::modules()->topic->doSomething();
Но надо смотреть, удастся ли сделать так, чтоб подружить с автокомплитом и PHPDoc, ибо это несомненно большой плюс для разработчиков, использующих умные IDE
Возможно, не так красиво, но есть важное преимущество: мы явно указываем, что не к свойству текущего объекта обращаемся, а именно к модулю. И если даже какой-то новичок программер, не въехав в нюансы, создаст экшен в котором по ему ведомой логике объявит свойство $modules — он напрочь сломает вашу реализацию, а в моем варианте все будет работать.
Любопытное решение. И добавлю еще пару плюсов, которые проистекают от избавления от «магии»:
1) По идее должна увеличиться общая скорость отработки кода, т.к. вызов через «магию» — это все ж довольно ресурсоемкая операция, а таких вызовов в коде немерянно.
2) Появляется возможность передачи параметров по ссылке, чего иногда мне лично не хватало. Например:
class ModuleTopic {
public function Blabla(&$iCount) {
$iCount = 1;
return true;
}
}
по сущности своей, просто средство связи между БД и другими объектами
Нет, не БД, а источник данных, это авжный момент, т.к. я писал мапперы, которые работают НЕ с БД (в некоторых случаях это оправданно).
но так как маппер работает с таблицей...
Ни в коме случае! Если источником данных выступает все же БД, то маппер (как правило) работает с SQL-запросом, а не с конкретной таблицей. Это принципиальный момент.
И вообще, у меня такое впечатление, что Вы сейчас придумываете ОРМ, а он уже придуман и даже реализован :) Посмотрите в сторону EntityORM. Вот там источник данных завязан как раз на сущность. Но это два разных подхода к оперированию данными, которые живут параллельно, и не вижу смысла их смешивать
я предлагаю начинать с LowerCase, только геттеры и сеттеры, а остальное, только через Зглавную
Есть какая-то аргументация или так больше нравится? Может, сделать так: в объявлениях методов всегда использовать lowerCamelCase, а составных псевдовызовах эти же методы писать через UpperCamelCase? Т.е. так:
Class ModuleUser {
function getUsersByFilter() { }
}
Но псевдовызов этого метода оформляется так:
Но вызов оформляется так:
$this->User_GetUsersByFilter()
Вообще, в далекой перспективе мне хотелось бы изменить синтаксис псевдовызовов методов моделей и писать так:
маппер своим функционалом обеспечивает сущность или модуль
Модуль, никак не сущность. И очень важно понимать, что сущность, в общем случае, никак не эквивалентна одной записи в физической таблице. В ее основе — набор связанных данных, которые могут быть получены из множества записей множества источников данных (не только таблиц базы данных), в т.ч. и генерируемые по запросу.
Если модуль, то почему маппер представляет собой свойство модуля, как доп. объект, а не является частью его функционала напрямую через методы?
Самый простой ответ — так исторически сложилось. :) Не могу сказать наверняка, какая первоидея лежала в разделении, но могу предположить, что изначально задумывалось в модели (как она формулируется в MVC) абстрагировать функционал получения данных из источника с тем, чтобы можно было в перспективе использовать различные способы хранения и извлечения данных — SQL, noSQL, XML, etc.
GetUsersByFilter() — это, на мой взгляд, не геттер...
Да, это однозначно не геттер, даже обсуждать нечего, я лишь для примера привел, чтоб показать, что в одном случае тут метод класса, который начинается с «Get...», а в другом — метод класса, начинающийся с «get...». Но вообще геттеры/сеттеры в данном движке пока только в сущностях (Entity) предполагаются. Более того, это, как правило, некая надстройка над родительскими методами Entity->getProp()/Entity->setProp().
Но значит ли это, что все методы сущности должны писаться в lowerCanelcase, как считаете? Ведь в общем случае у сущности могут быть и иные методы, не только геттеры/сеттеры. Как предлагаете их писать?
В комментариях к прошлой статье extravert сказал, что для составных префиксов еще не время, и я с ним согласен. Сущности используются очень часто и писать две буквы вместо одной хуже
Ну так что у нас в префиксе? Тип? Или не тип? Очень не хочется мешать в кучу типы и классы
я предлагаю оставить за каждым маппером свою таблицу
Хм, неожиданно. Но пока не вижу серьезных резонов для такого шага
В админке «Настройки сайта / Ссылки» в параметре «Показывать на главной» задается «Домашняя страница». В папке скина создается папка /actions/ActionHomepage/ куда кладется файл index.tpl, который инклудит другой шаблон, в зависимости от того, авторизован юзер или нет.
Примерно так:
Меня, как разработчика, всегда слегка напрягало, что у движка, под который я пишу плагины, и на котором делаю сайты для людей, как-то «внезапно» выходит новая версия, где круто все меняется. Иногда это приводило к тому, что месяц-другой работу улетал псу под хвост, потому что срочно приходилось все переделывать.
Я знаю, что на Альто начинают делать серьезные проекты, писать нехилые плагины. Поэтому этот релиз — это, своего рода, анонс, который рассказывает не только о том, ЧТО нового будет в новой версии, но и КАК это будет реализовано, чтобы сторонние разработчики могли уже сейчас планировать, как можно будет использовать новые возможности движка в своих будущих разработках.
За багрепорт — спасибо.
Но надо смотреть, удастся ли сделать так, чтоб подружить с автокомплитом и PHPDoc, ибо это несомненно большой плюс для разработчиков, использующих умные IDE
Этот вызов в текущей реализации отработает в любом компоненте — сущность, маппер и т.д. Или речь о чем-то другом?
Но дополню: если и внедрять подобную реализацию, то я бы предложил чуть-чуть иной подход, а именно вместо:
реализовать что-нибудь типа:
Возможно, не так красиво, но есть важное преимущество: мы явно указываем, что не к свойству текущего объекта обращаемся, а именно к модулю. И если даже какой-то новичок программер, не въехав в нюансы, создаст экшен в котором по ему ведомой логике объявит свойство $modules — он напрочь сломает вашу реализацию, а в моем варианте все будет работать.
1) По идее должна увеличиться общая скорость отработки кода, т.к. вызов через «магию» — это все ж довольно ресурсоемкая операция, а таких вызовов в коде немерянно.
2) Появляется возможность передачи параметров по ссылке, чего иногда мне лично не хватало. Например:
Вот такой вызов ничего не вернет в $iCount:
А в Вашей реализации, похоже, сработает как надо:
Ни в коме случае! Если источником данных выступает все же БД, то маппер (как правило) работает с SQL-запросом, а не с конкретной таблицей. Это принципиальный момент.
И вообще, у меня такое впечатление, что Вы сейчас придумываете ОРМ, а он уже придуман и даже реализован :) Посмотрите в сторону EntityORM. Вот там источник данных завязан как раз на сущность. Но это два разных подхода к оперированию данными, которые живут параллельно, и не вижу смысла их смешивать
Но псевдовызов этого метода оформляется так:
Но вызов оформляется так:
Вообще, в далекой перспективе мне хотелось бы изменить синтаксис псевдовызовов методов моделей и писать так:
Но это сугубо личные предпочтения
Самый простой ответ — так исторически сложилось. :) Не могу сказать наверняка, какая первоидея лежала в разделении, но могу предположить, что изначально задумывалось в модели (как она формулируется в MVC) абстрагировать функционал получения данных из источника с тем, чтобы можно было в перспективе использовать различные способы хранения и извлечения данных — SQL, noSQL, XML, etc.
Но значит ли это, что все методы сущности должны писаться в lowerCanelcase, как считаете? Ведь в общем случае у сущности могут быть и иные методы, не только геттеры/сеттеры. Как предлагаете их писать?
Хм, неожиданно. Но пока не вижу серьезных резонов для такого шага