Увидел в исходниках коммент:
/* usage:
* deplister.exe path\to\module.exe path\to\symbols\root
* */
Попробовал - очень похоже на то, что оно выводит список тех .dll, которые требуются в exe. Думаю вопрос закрыт.
@Fesor, неа. Как выяснилось гуглением - это немного другая очистка кеша, а именно всех данных, записанных с помощью методов класса Cache::* ( laravel.com/docs/cache ), так что нужна именно очистка директории ручками.
Вы правы, документация стрёмная. Потратил пол часа, что бы найти группы сериализации - не нашёл, есть вариант потыкать меня носом? Или исходники стоит смотреть?
З.Ы. Фрейм Laravel 4, но это думаю не существенно.
Насколько я понял он ориентируется по аннотациям класса сериализуемой модели, верно?
Функционал скрытия данных при сериализации модели уже присутствует внутри фреймворка, который я использую, но проблема в том что в разных местах требуется получать разные данные, используя одну и ту же модель, т.е. отвязаться от унификации данных и фильтровать их на ходу.
Пока набросал примерчик "в лоб": pastebin.com/AeuGMwET Но как понятно - он очень простой и не позволяет строить сложные структуры, т.е. на каждый чих придётся лезть в исходники и править их.
Я старательно пытаюсь поведать требования, которые исходили из возможности индексации страницы, что я и сообщил в вопросе (может немного иносказательно). То что это ria - очевидно, иначеб и вопроса подобного не возникало. Просто в результате я пришёл к идее, вместо разделения статики (с помощью указанного вами выше PhantomJS, например, или серверного шаблона) и клиентского (Knockout, Angluar, etc...) - просто их совместить в одном движке. А то что данные приходят из JSON ответа от сервера или из контроллера - волновать особо не должно. Данные они и в Африке данные.
На ресурсе происходит редзайн, вместе с этим решили переписать фронт-энд. Основная цель всего этого мероприятия, помимо более вменяемого кода — уменьшить траффик, который забивает канал хостинга, проблема пока только в поисковиках и в пользователях без js. По этому ищу наиболее вменяемое и простое решение для этой проблемы.
Ну на счёт моделек и контроллеров — это да. Кодогенерация — плохое решение всегда (если конечно это не специально заточенный DSL). Только контроллеры в любом случае будут отличаться — всё же логика разная — одно — просто передача данных и обработка гет\пост событий — другое — обработка пользовательских событий, анимашки всякие, финтифлюшки и прочее, общее — только указание аргументов шаблону. Чисто теоретически — от клиентских моделей при таком подходе — тоже можно отказаться — передавать данные сразу в контроллер, пусть это и повышение объёма загружаемых json данных за счёт дублирования повторяющихся данных, да и сам подход, прямо скажем — не очень, но уменьшение объёма работ и гарантированная актуализация данных. А если заиспользовать вебсокеты, то разницы практически не будет заметно, что 5 килобайт, что 10. В общем это довольно спорный вопрос — единственное что действительно будет дублироваться — это роуты.
1) нет пространств имён (устарел)
2) исходники местами ужасают (как слишком придирчивый любитель PSR, не принимайте близко к сердцу)
3) что бы просто сделать компиляцию ассетов из scss\coffee — пришлось потратить тучу времени (в Laravel к слову сделал это за час, только начиная работать с этим фреймом)
3.1) соотвтесвенно из-за архитектуры — реализовать нормальный аналог ассет пайплайна (сборка и минифицирование всех ассетов) — трудоёмкая задача (с Laravel пока таким не занимался, и не в курсе проще\сложнее ли)
4) конфигурация более чем монстрообразна
5) есть вещи, которые можно сделать намного проще, на память не припомню, так что можно смело игнорировать этот пункт
6) не нравятся роуты, в Laravel наоборот, более чем: laravel.com/docs/routing
7) дофига всяких мелочей о которые спотыкаешься после непродолжительной работы с RoR
Это лично моё мнение после обзорного знакомства с Yii, возможно оно всё там есть и более чем удобно, но учитывая то, что в Laravel большинство столь полезных плюшек находилось\делалось с пол пинка — я бы в споре «Yii против Laravel» — ставил бы на второй пункт =)
