Модель ссылок в Kohana

Без знания смысла разделения ссылок на группы сказать что-то трудно. Например, почему нельзя определить роли числом и показывать ссылки с "ролью" не больше текущей роли пользователя?

У незалогиненного пользователя по идее Роль должна быть = 0, или Guest, если словами (но Роль всё равно надо присваивать).

роли итак определены числом - своим idшником..
потому что нет гарантии, что id роли не будет меняться)) допустим есть роль 1 - просто юзер, 2 - админ, 3 - группа_1, 4 - группа_2, показать ссылку_1, например, надо группе_1 и админу, ссылку_2 - юзеру и админу, ссылку_3 - админу и незарегенным.. 1 и 2 меняться вряд ли будут, а вот 3,4 и т. д. - вполне, причём "не больше" тут просто не подходит, "не меньше" тоже.. тут можно без третьей таблицы записывать в какое-нибудь поле роли через запятую, но с ними тогда работать сложнее.. роль может удалиться, потом снова добавиться, id её получится больше, а условиями больше или меньше мы средние роли никак не уберём
у незалогиненного роль NULL если получать через Auth, но в базе ролей её нет, то есть JOIN'ом я её не получу..

я думаю тебе лучше обратиться сюда http://kohanaframework.org/index#community
так как вопрос заязан на конкретный фреймворк.

я там уже написал, правда в русскоязычной ветке)) но похоже, что прийдётся и на английском писать

Не могу сдержаться и не заметить, что кроме самого PHP программеру работающему с данным языком через фрейворк приходится учить еще и это фрейворк и зачастую задаваться вопросов "как, *****, Х задачу вписать в Y модуль".

Часто в такие моменты думаю, реально ли ускоряет работа на фрейворке время разработки или нет...

Я понимаю вашу иронию, но в этой задаче и модель юзеров и модуль авторизации вообще пришлось переписывать, чтобы нормально хранить данные с OpenID и oAuth авторизаций, а с ними уже нормально была написана и модель ссылок для групп пользователей.
Я бы не сказал, что он (фреймворк) сильно может ускорить время разработки, если случай сложнее "написать сайт-визитку для компании за неделю", но он избавит от многих костылей и меньше прийдётся проводить рефакторинг в будущем.

Я ничуть не иронизирую. Я абсолютно серьезно. В практике сталкивался либо с уже готовыми CMS в которую нужно что-то запилить, причем на уровне чисто PHP/SQL кодинга, а не разработки с использованием CMS, либо же с вовсе кастомными разработками в которых только PHP/SQL только и есть.

Но вот что бы так чисто что-то запилить на фрейворке и прикинуть ускорил бы он меня не приходилось. Была одна попытка в самом начале когда пытался сделать каталог для инет магаза на Zend. Но ни чего не получилось, он оставил о себе только отрицательно впечатления в контексте задачи "сделать сайт". Поэтому сделал врукопашную на PHP+MySQL заведя под XSLT шаблонизатор. Возможно был молод и не постиг дзен Zend-а?... Но XSLT то мне раскурить и применить получилось...

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

С готовыми CMS - это понятно, в лучшем случае необходимый модуль прийдётся дозаказывать у разработчиков CMS, в худшем - как вы описали - пилить самому.

С Zend'ом я тоже сталкивался на уровне потрогать, но знаю, что у товарища в реальном проекте, когда он был готов уже на 80%, было решено отказаться от зенда, который использовался как драйвер для собственной ORM, и переписать всё ручками.

Вообше лично я реально использую в фреймворке Kohana только ORM, которая, имхо, наиболее близка к идеальной на мой взгляд python'овской sqlAlchemy. Ни в одном другом фреймворке, ни в отдельных ORM-ах не встречал ничего похожего. Но sqlAlchemy юзает магию питона и форкнуть его не получится. Хотя мысли такие были. Из остального только что шаблонизатор, который можно написать за пару часов и забыть про него, ну и иерархическая файловая модель, которая завязана на __autoload и подгружает твои классы.

А в целом я чуть выше написал, имхо, но повторюсь: фреймворк не особо сильно ускорит время разработки, но фреймворк позволит ускорить работу сайта за счёт использования проработанной магии языка и прочих подобных унифицированных вещей, сократив таким образом время на низкоуровневый рефакторинг на поздних стадиях разработки. Ну и не PHP единым, Django для Python'а или Rails для Ruby ускорят разработку однозначно, просто потому, что в противном случае вам прийдётся реализовывать почти всё, вплоть до ручной отправки хедеров или вообще собственного HTTP-сервера))

Это смотря относительно чего сравнивать. Если сравнивать с решением, которое вы напишите сначала, то с 90%ной вероятностью фреймворк будет работать быстрее) Если сравнивать с решением после проведения всех оптимизаций и под конкретную задачу - то нет. Но сколько вы потратите на такую оптимизацию - уже другой вопрос.