Предположим, что у нас есть общий класс задач. Скажем, вывод файлов, валяющийхся в одном подкаталоге. Роутится, например, по правилу
.*/files/? => mysolution_page_files
Или, например, поиск среди определённых объектов:
/items/search/? => mysolution_items_search
Всё хорошо, но автоматизация дошла до того, что в 99% случаев у меня
class mysolution_items_search extends mysolution_meta_page_search { }
а
class mysolution_meta_page_search extends framework_meta_page_search
{
function solution_name() { return 'mysolution'; }
}
При чём это я уже развёрнуто описал, обычно оно в YAML, ещё короче. При чём для варианта /items/search/ даже route не нужен, он в _meta_search автоматический.
Я страшно не люблю писанину и копипаст там, где без них можно обойтись. По идее, можно отказаться от этих врапперов, перейдя к автогенерируемым по route классам. Что-то типа записей в конфиг-классе проекта или в списке врапперов:
.*/files/ => auto_class('cat')
/items/search/ => auto_class()
Типа, в первом случае обработается цепочка mysolution_auto_cat_files => framework_auto_cat_files (а вся конфигурация запихнётся в mysolution_auto_cat_files, всё равно он автоматический), во втором: mysolution_auto_items_search => framework_meta_page_search.
Ну, тут уже возможны вариации, так как у меня на этом уровне без автоматизации в разных проектах есть разброд с названиями.
Вот тут, как раз, и возникает вопрос унификации терминов.
1. Как бы получше назвать эту систему. В том смысле, что _auto_ — как-то слишком неопределённо. Может есть какая-то общая мысль?
2. Частный случай — как назвать обобщающе задачи вывода элементов? То, что я тут от балды обозвал cat? При чём, если подумать, то и задача вывода элементов из каталога, и задача вывода результата поиска — они относятся к одному классу.
