Как в ваших фреймворках называется такая сущность?

0

2

Предположим, что у нас есть общий класс задач. Скажем, вывод файлов, валяющийхся в одном подкаталоге. Роутится, например, по правилу

.*/files/? => mysolution_page_files

Где mysolution_show_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? При чём, если подумать, то и задача вывода элементов из каталога, и задача вывода результата поиска — они относятся к одному классу.

Ссылка

←	JavaScript надежность

javascript lint?

→

Кстати, в случае расширения списков роутинга тоже вопрос, как лучше оформить такое. Сейчас у меня используется несколько форматов записей:

# прямая привязка url к имени класса:
/path/to/page/ => mysolution_some_page

# привязка с передачей ID:
/items/(\d+)/ => mysolution_item_view(1)

# Перманентный редирект на новый URL, выдаваемый классом
/old-items/(\d+) => redirect:mysolution_item_view(1)

# Загрузка списка роутинга из субкаталога, который будет базой для относительного роутинга:
(/admin)(/.*) => include(mysolution_admin)

Надо бы, наверное, как-то покрасивее и автоклассы сюда вписать.

~~KRoN73~~ ★★★★★
(14.10.12 15:40:52 MSK) автор топика

Ссылка

/path/to/page/ => path_to_page.php
/path/to/page/a/ => path_to_page_a.php
/path/to/page/a/b/c/d => path_to_page_a.php + ['path' => 'b/c/d'] 
/path/to/search/a/b => path_to_search.php + ['path' => 'a/b']

1. Как бы получше назвать эту систему.

2. Частный случай — как назвать обобщающе задачи вывода элементов?

view -> render

swwwfactory ★★
(14.10.12 22:35:05 MSK)

Ссылка

чем отличается mysolution_items_search от mysolution_meta_page_search в оставшемся 1% случаев?

bismi ★
(15.10.12 14:23:11 MSK)

Ответ на: комментарий от bismi 15.10.12 14:23:11 MSK

чем отличается mysolution_items_search от mysolution_meta_page_search в оставшемся 1% случаев?

Дополнительные фильтры выборки, нестандартные имена классов, нестандартная сортировка вывода, нестандарные шаблоны вывода и т.п.

~~KRoN73~~ ★★★★★
(15.10.12 14:32:42 MSK) автор топика

Ответ на: комментарий от KRoN73 15.10.12 14:32:42 MSK

Если только в 1% нужна кастомизация, то может пойти другим путем, и использовать напрямую framework_meta_page_search, а для кастомизация передвать туда структуру с параметрами.

Вот взять джангу, там были function based generic view, в функцию передвались параметры, потом они решили перейти на class based generic views потому что так вроде параметризировать легше, переопределяя при наследовании. Но можно ведь было в function based generic view передвать структуру/объект например config со всем необходимым хозяйством.

Как там у классиков: «программируйте через композирование, а не через наследование»

bismi ★
(15.10.12 16:35:45 MSK)