Иван

Не знаю, что именно Вы хотите проверять, но возможно подойдет https://www.reformagkh.ru/. Там можно просто парсить информацию зданий или запросить доступ к их API.

array_combine(
    array_map($array, function($a) {return $a['name'];}), 
    $array
);

array_combine() создает массив из переданных аргументов (первый - массив ключей, второй - значения). для извлечения ключей используем array_map.

Естественно, это ооочень упрощенный вариант, основанный на предположении, что всегда есть ключ name, а значения в нем уникальны.

Наверняка некоторые элементы повторяются на странице для каждой строки (я про эти пять инпутов). Почему бы не вынести их в отдельный Popup, а данные для отдельных элементов не хранить в JS или в hidden? И отдавать данные JSON'ом будет проще…

Я вовсю пропагандирую Kohana )) ИМХО, фигня насчет документации.

Официальный мануал на английском
Неофициальная вики (сборник рецептов)
Отличный форум (в том числе и русская ветка)
Куча русских мануалов (kohana3.ru, kohanaframework.su, 101.brotkin.ru) и блогов

По поводу рефакторинга — ну он же в правильном направлении идет )) Тем более, что последняя ветка (3.3, еще пока RC) ИМХО достаточно красиво выглядит, чтобы этот самый рефакторинг на ней закончить.

ИМХО, задача реквеста — принять входящие данные (POST/GET/COOKIE и прочие заголовки), инициировать запуск нужного метода контроллера, и вернуть реквест с результатом. Соответственно, вся логика (валидация, запросы к БД и т.д.) должна лежать в контроллере, но не запросе. Request — служебный класс, и его имеет смысл разбивать на подклассы, если возможны различные варианты обработки входящего запроса, но никак не подстраиваться под бизнес-логику.

НЕ Kohana ;) Но, в целом, с любым фреймворком будет сложно, если не знаешь языка. Да и как читать php.net и StackOverflow без английского?

Отвечу как пользователь фреймворка Kohana (с той самой КФС).

В проекте имеются условные папки Application, System и Modules (естественно, названия могут быть любыми). В System хранится код ядра фреймворка (базовые классы для роутинга, MVC/HMVC, хэлперы и т.д.). В Modules — куча подключаемых модулей, как стандартные (Database, ORM, Cache и т.д.), так и собственные разработки. Ну и в Application остается код, специфичный для данного приложения (т.е. который Вы не планируете переносить на другие приложения).

Любой используемый модуль должен быть явно объявлен в системе (Kohana::modules($module_list)). При добавлении модуля (или списка модулей) происходит следующий алгоритм:

0. В главном классе модуля есть статическая переменная $_paths, в которой хранятся все пути КФС. Изначально в него добавляется путь к Application.
1. Проверяется путь к модулю, если нет — модуль игнорируется.
2. Модуль добавляется в $_path. Делается проверка на существование файла init.php в корне модуля. Если он есть, то выполняется. Таким образом, можно осуществлять какие-то стартовые действия (загрузка конфигов, добавление роутинга и т.д.).
3. Последним в список добавляется System.

Структура файлов и папок одинаковая, что в Application, что в System, что в каждом модуле. После выстраивания списка путей в ряд мы получаем возможность проходиться по нему в поиске нужного класса. Например, если есть модули A, B, C, а в B и C имеется класс Foo, то система выберет класс из модуля B, так как он идет раньше в списке путей. На очередность влияет порядок упоминания классов в списке вызова Kohana::modules(). Пути при каждом запуске генерируются заново, но вот результаты поиска файлов кэшируются, чтобы меньше шуршать по винту.

Для понимания такой структуры очень полезно посмотреть на эту картинку. В результате часто собственно проект (Application) состоит из конфигов и файла запуска (bootstrap), все остальное выносится в модули.

Кроме того, гибкость и расширяемость фреймворка достигается засчет «пустых» классов, например есть Database и Kohana_Database (extends Database). Весь изначальный функционал реализован в Kohana_Database, но в коде мы используем Database. Соответственно можно где-то в Application или в одном из модулей добавить свой класс Database (в таком случае система загрузит его, а не аналог из System), и в нем сделать нужные изменения.

PS. А эвенты все равно удобная штука (хоть и достаточно простые — Event::add() и Event::run()). Их в Kohana v3 штатно уже нет (т.к. имеется достаточный контроль над выполнением Request'а), поэтому приходится вручную прикручивать для собственных событий.

Гм… А Вам не кажется, что что-то неправильно в используемом Вами алгоритме? Попробуйте его описать тут, может придумаем что-то.

Очевидно, что выполнять действие должен объект, располагающий исходными данными в максимальном объеме. А данном случае это $a (он содержит как объект класса B, так и свойство $a->e). Скорее всего он не может выполнить все действия из метода $a->c->d() по все той же причине, поэтому внутри нашего идеального метода $a->x() должен вызываться $a->c->d() для получения данных об $a->c.

Конечно, можно все это сделать просто сохранив в объекте $a->c ссылку на родителя, но по мне это скорее костыль.

Не гонитесь за голыми цифрами. Надо искать оптимальную точку пересечения графика «удобство» с графиком «скорость». Можно сделать класс для генерация меню, который будет максимально быстро отрабатывать, но сделать шаг влево-вправо в нем нереально. А можно наоборот.

Сами тесты вообще «в вакууме». Обратиться к БД можно прямым запросом, можно через конструктор запросов, а можно и ORM подкрутить. Скорость падает, но растет удобство.

Я бы посоветовал поковыряться в основных фреймворках (не только быстрых, типа Kohana или YII, но и в монстрах типа ZF), дабы почерпнуть основные идеи, которые Вам покажутся действительно важными. В принципе, так сейчас строятся все новые фреймворки — как результат работы над ошибками других конкурентов.

Я там выше в комментах уже отписался про Kohana. Отличный фрейморк, смотрите сразу на 3.0. Ничего лишнего — изначально качаете ядро, все остальное (даже Database) добавляете по желанию. Документации конечно не так много, как у CI, но в принципе достаточно. Что непонятно — на форуме выясните (есть русскоязычная ветка). Есть блоги про Kohana, как на русском, так и на английском.

Кстати, к концу года должна выйти версия 3.1, там вроде как интересности всякие добавятся.

Интересно, при чем тут ориентированность на мобильных пользователей? Каких-то особых требований Вы не привели :)