Структурирование Zend_Acl и CRUD с отношениями родитель / потомок

Мне интересно, как мне структурировать свой ACL для CRUD с отношениями родитель / потомок.

Например. В проектах есть списки TodoLists. В списках Todo есть Todos

Существуют различные действия контроллера для проекта

• / projects / add
• / projects / edit / {projId}
• / projects / delete / {projId}
• / todo-lists / add / {projId}
• / todo-lists / edit / {todoListId}
• ...

Как вы можете видеть, спускаясь по иерархии, некоторые действия имеют идентификаторы, которые относятся не к себе (например, контроллер todo-lists -> ресурс todo-list), а к их родительскому элементу.

Итак, если у меня есть настройка (обычно), это выглядит так

• ACL Controller Plugin (preDispatch)
  • Set role to loggedin user or 'unauthenticated'
  • Задайте для ресурса имя контроллера
  • Установить привилегию на имя действия
  • если задан параметр запроса id, получить фактическую сущность (я использую Doctrine ORM), которая реализует Zend_Acl_Resource_Interface. Вот здесь и возникает сложность. Обычно я получаю ресурс по имени контроллера, но, например, с /todo-lists/add я должен знать, чтобы вместо этого получить родительский объект (Project). С этой настройкой мне придется изменить привилегию на что-то вроде «addTodoList». Таким образом, класс утверждения acl проекта будет иметь материалы TodoLists. Также будет разрыв между действиями контроллера и логикой ACL. Это нормально?

Может быть, мне стоит добавить addTodoListAction в ProjectsController вместо TodoListsController? Это упростит мой код ACL, мне не нужно будет проверять и изменять ресурсы / привилегии? Я могу просто взять их прямо из параметров запроса (имена контроллеров и действий).

Как вы настраиваете ACL таким образом?