Да, как только администратор выделит сервер для внешних тестов. Основа развёртывается вручную, ядро пишется в Notepad++. Всё сурово, в лучших кустарных традициях Как бы эту поделку преподнести сообществу? Пример заготовки под модуль (контейнер логики) блога: Код (Text): <?php // Модуль Blog. Контейнер логики. // FrontModule - можно подключить к страницам внешки (доступен в списке выбора) // class Blog extends FrontModule { public static function getSummary() { return array( 'title' => 'Блог', 'icon' => 'news.png' ); } // «Пути-дорожки» композитора контрольной панели // Обрабатывается как /STATIC_BACK_PATH/action-path/with-any-slashes // т.е., /admin/action-path/, где 'action-path' - ключи возвращаемого методом массива. // public static function getBackActions() { return array( 'blog' => array( 'type' => self::AR_ITEM, //'key' => 'Blog editor', # Роль, которой должен обладать пользователь 'title' => 'Действие из ветки Back', 'callback' => 'backSample' ) ); } // «Пути-дорожки» для композитора внешки. // Обрабатывается как /DYNAMIC_FRONT_PATH/action-path/with-any-slashes // public static function getFrontActions() { return array( null => array( 'type' => self::AR_TEMPLATED, # На выходе задействует шаблонизатор, ожидает массив блоков для заполнения регионов. //'type' => self::AR_JSON, # Преобразует выходной массив в JSON //'type' => self::AR_PLAIN, # Завершит сценарий по выходу из метода (аналог void, скорее так и назову) //'module' => __CLASS__, # В каком модуле-соте запросить callback? По умолчанию - текущий модуль 'callback' => 'startup' ), 'tag' => array( 'type' => self::AR_TEMPLATED, 'module' => 'Blog_Tag', # Тело для работы с сущностью тега, хотя можно создать метод и в рассматриваемом модуле. 'callback' => 'tag' ), 'json/tag' => array( 'type' => self::AR_JSON, # На выходе задействует стандартную функицю json_encode 'module' => 'Blog_Tag', 'callback' => 'getJSON_tag' ) ); } ## ## Методы взаимодействия с «пчелой-композитором» Front (внешкой) ## public function startup() { // // TODO: Place the Blog startup page logic here... // return array( 'headline' => 'Контент блока уровня M для региона headline', 'details' => 'Контент блока уровня M для региона details' ); } ## ## Методы взаимодействия с «пчелой-композитором» Back (контрольной панелью) ## public function backSample() { return array( 'content' => 'Зона вывода одна, а слева панелька меню' ); } } Копируется в папку modules и сразу становится виден в контрольной панели, доступен для подключения.
Pran, а ну примерно ясно ) в прицнипе ничего интересного по сравнению с симфони2 нету... а вы случано не собираетесь переходить на симфони?
Нужно составить примерное представление с основ, как там чего делается - возможно, заменю движок на что-то более прогрессивное. Хотя интереснее взять лучшее от разных систем и собрать в одну. Сколько времени в Симфонии затрачивается на формирование одной страницы, наполненной только текстовыми блоками? С подключенной «нодой-блованкой» без логики? Что делать, если нужно получить от некоторого пути ответ в формате JSON? Насколько принципы кустарного движка похожи на принципы Симфонии? Где они перекликаются, а где разнятся? Среднее время обработки запроса без ускорителя wincache и без ресурсоёмких бизнес-операций в моём случае 0.012-0.017 сек, изменение памяти на момент отдачи в браузер (PHP 5.3) - 444.27 Кбайт. Если я правильно понял, к регионам на странице Симфонии можно подключить разные модули? В моём случае модуль может использовать любой регион, затирая то, что могло быть помещено в него ранее.
про симфони лучше читать документацию буквально с самого начала ) по "скорости" симфони обычно будет проигрывать якобы аналогам, не потому что сф2 такой тупой и монстроузный, а потому что то что ставится ему в просивовес это несерьёзные и ограниченные поделки, в которых могут разобраться несколько человек на планете ) такой поделкой можно считать и мою бывшую цмс-ку, демо которой можно посмотреть на http://digi.tw1.ru/ , но сейчас я переделываю двиг на симфони, по скорости он теперь стал "медлеенее" ) но эта замедлительность в выполнении с лихвой перекрывается гибкостью и надежностью разработки, а также потенциалом платформы. например на данный момент показатели главной страницы вот такие: Execution time: 20 ms. Memory usage 3.51 MB (3.79 peak). DB query count: 18 (summary execution time: 4 ms, 21.95 %). это крутится на виртуальной машине virtualbox, вот пхпинфо с неё http://smart-core.org/phpinfo_gentoo_x64.html на хостовой машине win7 64bit и проц i5. в прицнипе с такими показателями можно смело браться за создание хайлоада т.к. многие вещи можно скешировать на самых разных уровнях. еще добавлю, что 32-х битная система http://smart-core.org/phpinfo_gentoo_x32.html работает медленее на томже хостовом копмпе: Execution time: 23 ms. Memory usage 1.94 MB (2.14 peak). DB query count: 18 (summary execution time: 6 ms, 24.06 %).
ну что, товарищи? с летних отпусков начинаем выходить? какие мысли по дальнейшему развитию темы? а то как-то неоконченность разговора ощущается
„Чтобы стоять, надо держаться корней.“ Хорошо выдумывать свою терминологию и изобретать велосипеды. Это я без издевки, действительно считаю, что изобретать полезно. Но хорошо бы при этом четко знать какие велосипеды уже есть. Удобную концепцию предлагает нам сам протокол HTTP. В центре всего стоит ресурс — веб-страница, изображение, данные в формате JSON, что угодно. Ресурс: URL (Uniform resource locator) Действие с ресурсом: HTTP-метод GET, POST, etc. Представление: HTTP-заголовок Accept Популярная сейчас архитектура REST это и есть концептуальный возврат к корням. Переложение техники MVC на веб несколько увело программистов от сути. Когда в обсуждении я вижу термин экшен контроллера, я понимаю, что скорее всего он подразумевает свой отдельный адрес, то есть вместо ресурса (существительного) мы получили действие (глагол). На написание этой кучи букв меня подвигла статья Introducing the RMR Web Architecture, в которой автор предлагает свою объектную модель, примиряющую MVC и REST. Кому интересно, я сделал свободный перевод.
прочитал перевод, ничего нового не увидел, Symfony2 и есть НЕ mvc фреймворк, это request-response фреймворк.
HTTP существует с 1991 года, очень не новая вещь ))) Можете рассказать что нового Вы обнаружили в Symphony2.
c Symphony2 дела не имел, только с Symfony2. понятия "новое" оно всегда относительное вы можете рассказать о концепции RMR в сравнении с Symfony2?
Ок. Я нашел конкретный пост где Фабьен Потенциер (я правильно произнес?) объясняет является ли Симфони2 MVC фреймворком. капец, он мог бы работать политиком, так гладко ответил "да" и "нет, потому что". Я подозреваю, что Фабьен это бог или хотя бы мессия, за ним идут легионы. Симфони2 это набор компонент и главный плюс в том, что они слабо связаны. Про то, насколько они гладко ложатся в архитектуру REST или еще во что, можно будет говорить только на примере готового приложения. Статья про RMR напротив описывает "клей" для построения RESTful приложения и не заморачивается конкретными компонентами. Типа того )
У автора есть фреймворк и на эту статью ссылаются на stackoverflow — я так на неё набрёл. Не в курсе на скольких разрабов она повлияла. Вот на эту тему на форуме пока никто не ссылается, это не повод для комплексов )))
ясно, ну да, вот и жду тех 2-х ребят, которых больше всего теории описали в начале темы, вдруг они смогут что-нить показать