Спасибо за комментарий.
Часть предложенных принципов я поддерживаю:
— соотношение пользователей и ролей многие ко многим
— роли и организационные группы это не одно и тоже
От части идей я предпочёл отказаться, потому что, как мне кажется, это ненужное усложнение
— наследование ролей
— назначение прав напрямую пользователям. Это с точки зрения базы. А с точки зрения пользовательского интерфейса можно назначать права пользователю, а записывать их в его «персональную» группу. Но этот подход выходит за пределы моего базового решения. Просто предлагаю варианты.

Если бы я вдохновлялся вот этой реализацией, я бы получил:
— «непоследовательную» ACL в которой «система вернет вам последний измененный параметр»
— наследование ролей

Лучше бы вы это здесь не оставляли. Идеи которые предлагает Zend_Acl:
— множественное наследование ролей. Это вообще «сказка» для хранения в базе (если нужно будет перейти от хранения в коде к хранению в базе.
— отсутствие принципов решения конфликтов

IMHO велоустройство через чур complexed.

Да простое же как грабли. Разбито на модули. Даже может работать с флагом admin в таблице user (куда уж проще). Но если изначально использовать заложенные принципы и программные интерфейсы, то легко расширить до решения с редактированием.

Btw, почему мы именуем DSL`ом то, что им не является? :)

Термин DSL я использовал так же как его используют в ruby. Любое множество специфических функций там называют DSL. Например, функции для написания Gemfile.

> на практике полезут вопросы производительности
Все вопросы производительности рассмотрены. Для этого как раз и не делается наследование групп и не даются права напрямую пользователям. Структура получилась «плоская», так что запросы будут простые и красивые и кеширование сделать тоже будет просто.
> и муторность конфигурирования
Не вижу такой проблемы. В коде ничего конфигурировать не надо, потому что CoC. Сбор данных автоматизирован максимально. Можно задавать изначальные значения с помощью DSL (эти файлы будут хранится в системе контроля версий и накатываться автоматически так же как фикстуры на базу).
> Есть еще вопрос аудита — например, хочется знать, юзер редактировал пост потому что ему прав хватило, или потому что он модератор.
Не очень понял проблему. Смотрим на пост и видим кто автор поста.
> А правило например «может редактировать свои посты в течение 30 минут».
can_edit_30(user, resource) return user.id == resource.user_id && (resource.created_at - now()) < 30; end
> Если не различать — логи забьются шлаком.
Поподробней пожалуйста.
> IMHO, оптимальнее всего отталкиваться от реальной задачи, максимально упрощая для нее логику ACL. На «классические» реализации вас ссылки уже дали, тут добавить нечего.
Я как раз все упрощал. А эти реализации все усложняют. Не очень понял почему это «классические», реализации. Я бы назвал классической реализацией, например, права в файловой системе *nix. Именно из этой системы была взята идея о том, что у юзера может быть много ролей (больше ничего подсмотреть не удалось).

> страсть перегорает, в то время как жадность устойчива
Улыбнуло.

• Требования к формальному образованию базовые или отсутствуют
• Хорошая компенсация, даже для посредственных работников
• Миллионы рабочих мест
• Никаких физических усилий
TRUE!

• Никаких рисков здоровью или юридических рисков
Про юридические риски — по разному бывает

FreeArc, кстати, как и 7Zip, бесплатен и у него открытые исходные коды.

Было бы замечательно, если бы эти исходные коды выложили на Github.

fatal можно обработать если set_error_handler выполнился в не в том файле где случается фатал

Цитата с php.net
The following error types cannot be handled with a user defined function: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and most of E_STRICT raised in the file where set_error_handler() is called.

Скорее всего дело в этом. Если нет, выложите пример кода.

2Offenso. Достаточно будет, если я напишу это в комментарии?
Код распространяется под «лицензией» AS-IS. Вы можете копировать, модифицировать код без указания автора и без уведомления автора. Можно использовать в коммерческих проектах. Хотя сейчас, мне этот код не кажется идеальным и я бы не использовал его в коммерческих проектах.

Мнения автора могут не совпадать с его точкой зрения (с)

Было бы не плохо завернуть все описные действия как Chef рецепт

Случайно нажал отправить

> P.S. Будем рады если кто-то сможет оптимизировать код для генерации картинок бОльшего разрешения.

Если пиксели с одинаковым цветом идут подряд, то можно не создавать для каждого тег font, а объединять в один тег

> P.S. Будем рады если кто-то сможет оптимизировать код для генерации картинок бОльшего разрешения.

А как насчет компрессии цветов? Вместо #ffffff можно писать #fff; вместо #f00 можно писать red. Код такой компрессии можно подсмотреть в любом css minier'е

В исходном коде только два параметра _ga.trackSocial = function(opt_pageUrl, opt_trackerName), а у вас три. Откуда берется третий?

Opera 11 поддерживает css3 gradient -o-linear-gradient

Это бизнес логика тут надо быть внимательным. И если метод бросает исключение и нужно, что бы в месте вызова не прошло исключение значит его надо обработать там же.

переход явный throw new baseException(); — после этого ничего не выполняется в текущем методе.
Вы же не ожидаете, что что-то выполнится в функции после return;?

Я спросил про бизнес-логику.
1. Cначала оптимизируют ботлнеки.
2. APC
3. Есть еще кучу «микрооптимизаций» которые можно применить прежде чем станет заметна потеря производительности на исключениях

А если view надо отделить от model/control?