Dagdamor, а почему бы шаблоны не сделать совместимыми с xml? с наскока, кстати, твой движок у меня не завёлся, пришлось подправить хтакцесс: Код (Text): <IfModule mod_rewrite.c> allow from all RewriteEngine on Options +FollowSymLinks # RewriteCond %{REQUEST_URI} !^/admin/$ # RewriteCond %{REQUEST_URI} !^/user/$ # RewriteRule ^([^.]*[^./])/$ /$1 [R] RewriteRule ^admin$ /admin/ [R] RewriteRule ^user$ /user/ [R] RewriteRule ^phpcimage/([^./]+)$ /phpc/getimage.php?image=$1 [L] RewriteRule ^([^.]*[^./])?$ /phpc/index.php [L] </IfModule> ps: зачем админку на фреймсете сделал? f5 выкидывает на главную страницу.
Горбунов Олег, ок, я не имею ничего против темплейтов в базе данных, но тогда нужен нормальный веб-редактор. текущий даже кнопку "tab" не поддерживает...
dark-demon Горбунов Олег XHTML вы хотите сказать? Я пока что идеологически против этого стандарта dark-demon "allow from all" наверное не стоит пихать в .htaccess - это возможная засада по части безопасности. Остальное... хм, наверное ты прав. Добавил в TODO
dark-demon С удовольствием добавлю - не проблема - но я пока что не видел ни одного хорошего (именно для правки шаблонов). Это вывод локализованного сообщения. Используется только в многоязычных проектах. Если тебе нужен сайт на русском и на английском - то да, такие вещи необходимы.
поэтому его надо либо написать, либо отказаться от хранения темплейтов в базе, либо прикрутить автоматический оперативный импорт из файла. а что, нельзя было никак сократить?
dark-demon Зачем писать свой редактор шаблонов? Пускай пока остается как есть, это же фреймворк. В будущем появляется достойный редактор HTML - я прикручиваю его к движку. Импорт шаблона из файла уже есть, сделать импорт сразу группы шаблонов вполне возможно (на форуме PHPC как раз недавно поднимался такой разговор), когда мы придем к чему-то конкретному - эта возможность перекочует в TODO. Обычно разработка сайта делается по схеме "верстка дизайна" - "формирование чистой страницы" - "перенос ее в движок". После этого работа над статикой заканчивается и начинается работа с динамикой. Там уже не столь важно, в чем ты редактируешь шаблоны. Но вообще согласен, хороший клиентский HTML редактор не помешает. На здоровье - <var:language:welcome>. Куда уж проще
Dagdamor, а, ну если сделал сайт, сдал заказчику и забыл, то да, "на этом работа со статикой заканчивается"... а с редактированием темплейтов пусть кто-нибудь другой мучается...
dark-demon Как раз вносить правки в шаблоны намного удобнее, когда они хранятся в БД: - не надо ничего скачивать/закачивать; - не надо тратить время на поиск нужного файла - все перед глазами; - в админке есть встроенный поиск и поиск/замена в шаблонах. Поддерживаются даже регулярные выражения.
Dagdamor, полностью поддерживаю. У меня основным методом хранения шаблонов тоже является база данных (хотя файлы также поддерживаются). Хранение шаблонов в базе данных позволяет с лёгкостью создавать очень удобные интефейсы их редактирования. Позагибаю как я пальцы... У меня поддерживается поблочное редактирование с автоматическим перечислением имеющихся в блоке заменяемых переменных и поиском среди фраз многоязыкового интерфейса фразы с идентифицирующим именем, как у переменной. Плюс есть возможность оставить комментарий относящийся именно к этому блоку (как общий, так и на всех поддерживаемых языках).
скачивать/закачивать нужно в любом случае ;-) а если хочется редактировать в более-менее комфортных условиях, то приходится ещё делать такие манипуляции: ctrl+a, ctrl+c, alt+tab, ctrl+v, редактируем, ctrl+a, ctrl+c, alt+tab, ctrl+v. поис и замена - это, конечно, хорошо, но без банальной подсветки синтаксиса в более-менее сложном темплейте чёрт ногу сломит. уж проще приконнектиться тоталом по ftp, найти нужный файл, нажать f4, отредактировать, закрыть редактор, нажать ок и переключиться на браузер, чтобы посмотреть результат.
dark-demon Не знаю, непосильная или нет, но я не знаю ни одной системы, в которой шаблоны хранились бы как файлы, и в то же время в их можно было редактировать в админке через веб-интерфейс. Видимо, все разработчики думают одинаково - "если шаблоны хранятся в виде файлов, зачем еще делать встроенный редактор? Пусть редактируют через FTP". ONK Может хоть одним глазком дашь посмотреть?
*bump* Накатал страничку для Википедии и поставил ссылку в подпись вместо старой. Шило на мыло конечно, но все-таки так будет поприличнее Если кому интересно - движок не заброшен, я понемногу готовлю версию 2.4.5.
*re-bump* Открылся долгожданный офсайт PHPC (ссылка в подписи). Олегу респект за дизайн. Правда, там всего 2 страницы, но это ничего-ничего
Dagdamor, извини, пожалуйста, но ты сам-то веришь, что вот это облегчает задачу, а не в сотни раз усложняет её? И я всегда думал, что админкой пользуется главный по контенту, а он не всегда умный (хотя даже умным нужна юзабильность). То есть, ты правда считаешь, что поля с именами "id", "image", "url" что-то говорят человеку добавляющему контент в базу, но не создателю базы? К полям нужно не только русское название, но и, сюрприс, русское описание (не в стиле "если указать алиас страницы, то 'снаружи'..."). Мало того, что "алиас" и "имя" у людей и у тебя кардинально различны (алиас это скорее короткое имя, а название - полное; ты опять удивлён, знаю ), так ещё и проверки от дурака нет. В том же примере про банеры. Если человек вообще ничего не введёт? "Пускай сам жалеет, что такой дурак" - не подход, он не юзабилин ни местом, так ещё и не фреймворковый. на сайте есть, а вот что им было "powered" не понятно. Вся информация лежит на форуме (даже дистрибутив). Форумы созданы для комьюнити, там обчуждают проблемы и придумывают решения. Из форума выносят в доки, но не доки пишут в форуме. Неужели с помощью фреймворка нельзя сделать страницу скачки и страницы доков с плоскими кейвордами, листалкой "туда-сюда" и оглавлением? Извини, если грубо где-то написал. P.S. Неужели eval()?
lexa Ссылки, которые ты привел - это мануал по созданию своего плагина. Разумеется, это задача не для контент-менеджера, а для программиста. Смысл: быстро разработать систему управления, которой потом сможет пользоваться любой, систему, которая сразу станет частью админки. То, что ты цитируешь - работа со страницами сайта, шаблонами, пакетами - это все функции разработчика (программиста). Защиты от дурака там действительно нет, как нет ее и в самом PHP. Если нужен именно редактор контента - ставь плагин "Редактор контента", там защита есть. Так сложилось исторически - форум существует уже больше года, все материалы накопились там, и релизил движок я тоже там. Офсайту еще нет и месяца, причем две недели из этого месяца я провел в отпуске. Разумеется, сайт надо развивать и понемногу "перетягивать" на него материалы. Это лишь вопрос времени. P.S. Да, eval. И тексты пакетов, и скомпилированные шаблоны отрабатывают через него. Еще раз: то, о чем ты говоришь - ипостась разработчика сайта.
Я наверное опишу вопрос админки более подробно У проекта есть разработчик, а есть контент-менеджеры и прочие "ограниченные" участники. В админке есть простейшая раздача прав: когда в админку заходит разработчик, ему отображаются все функции админки - в том числе закладки для управления страницами, шаблонами, пакетами. "Страница" в данном случае - это обработчик запроса, это может быть как одна физическая страница на сайте, так и целое семейство - как захочет разработчик. Контент-менеджерам все эти функции в админке недоступны - они могут лишь работать со своими модулями (тем же редактором контента, у которого возможности строго ограничены). КМ не имеет доступа к PHP коду и шаблонам. А вопрос разработки дополнительного модуля (плагина) для системы встает в любом фреймворке. У каждого сайта своя предметная область, свои нюансы, и стандартными новостями/галереями не обойдешься. Если эти две статьи выглядят слишком сложно и руками кодить неохота, можно установить готовый плагин для PHPC под названием "Генератор плагинов" - он берет 80% рутины при создании нового плагина на себя. Я обычно так и поступаю.
Так ведь в том и вопрос. Сделать крутилкку банеров задача элементарная, встоить её в CMS (с поддержкой модулей, плагинов, etc. - у разных СУК разные способы расширений) чуть сложнее. У тебя, мне так показалось, супер-сложно. То есть твой фреймворк не упрощает написание программы, а в разы усложняет его. Слишком много манипуляций нужно сделать чтобы решить простейшую задачку. Нарушает хорошии принципы 80/20 (80% времени пользуем результат, 20% пишем код) и K.I.S.S. (сделай это проще, дурачёк). Мне кажется, я понимаю чего ты хотел и даже одобряю идею, но не реализацию. То, что должно было упроститься работу стало её усложнять. Метод getRandomLines() чем лучше "order rand()"? Класс базы ведь не настолько "рубийный" (activerecord называется, по-моему; у Питона есть SQLObject, но в php всё-равно такого не сделать) чтобы мучиться избавлять пргограммиста от понятного ему sql-синтаксиса. Тем более, сложные запросы в методе не описать, а на запихивание простых в методы нэймспейсов не хватит или названия перейдут в трындец типа SelectFromBaseLimitAndOrderAndAnotherOrder. Воможно, это стремление к абстакции, но те же яйца вид сбоку. Боюсь представить размер доки по созданию чего-то с отношениями таблиц. "Делаем блог с категориями и комментами за восемь часов" . P.S. В PHP eval() запускает копию интерпритатора, что сильно сказывается на скорости. P.P.S. Понятное дело, всё ИМХО и для критики неплохо было бы познакомиться с фреймворком поближе, но мне просто не верится, что на нём можно сделать что-то действительно рабочее, хотя бы простенький блог. Больно движок "тепличный".
lexa Крутилка баннеров - задача элементарная, согласен, но в данном случае - это пример, который надо разжевать от начала и до конца, чтобы разработчик смог в будущем создать не баннерную крутилку, а скажем магазин или кадровое агентство. Супер-сложно? Что именно? Там две статьи, каждая состоит из 5 шагов. Всего 10 шагов. Первый шаг первой статьи: создание таблицы. Далее в том же духе. Все проиллюстрировано. *чешет затылок* Насчет класса для работы с БД: метод getRandomLines(), может быть, и не лучше, чем "order rand()", но уж всяко лучше, чем customQuery("SELECT * FROM $table ORDER BY RAND() LIMIT $limit"). Все виды запросов таким способом, конечно же, не покроешь, но наиболее часто используемые - запросто. В результате мы убиваем 3 зайцев: - вместо SQL в коде остаются короткие и "говорящие" названия методов; - нет необходимости писать одни и те же запросы снова и снова; - мы получаем неплохую степень абстракции от типа БД (хотя это и не является главной задачей фреймворка). Еще раз: если запрос простой - используешь готовый метод класса, если сложный - используешь customQuery(). Практика показывает, что такой подход оправдан - более удобной реализации класса для работы с БД я не видел ни в одном фреймворке. Откуда 8 часов? В PHPC практически любая задача разбивается на 2: модуль для админки и фронт-енд. Три сущности, на организацию управления каждой по полчаса. Плюс добавление комментариев в фронт-енде, еще полчаса. Отображение динамики во фронт-енде я не считаю - это вообще примитивная задача. Итого 2 часа. Ты с готовым скриптом блога будешь разбираться столько же. Никогда о таком не слышал. Сам замерял скорость отработки eval() - при отсутствии опкод-кеша время не отличается от времени отработки аналогичного PHP скрипта. Если опкод-кеш установлен - скрипт отрабатывает быстрее (за счет экономии на повторном парсинге кода). Но мы говорим об отработке пакетов PHPC - там, как правило, кода совсем немного и затраты на его повторный парсинг - совсем уж мизерная величина. realities.simpworks.com - powered by PHPC Фан-арт/фанфикшн, категории, галереи, рисунки, комментарии. Вполне рабочий проект, хоть и некоммерческий.
dark-demon А что - можно сделать. Только не по созданию блога (ну не люблю я блоги...), а что-нибудь типа магазинчика - было бы просто здорово.
Dagdamor, ты говоришь "просто", но не показываешь. Я видел пример банерокрутилки и это долго (разжёвывание не учитывается). "Говорящии" методы это очень сильное имхо, для кого-то одно для кого-то другое. RandomRows() понятнее (и без Get, ибо понятно что не собираемся мы Set делать). Ты привёл сложный код, с переменными внутри. Такой код всегда сложнее читать. Есть же плейсхолдеры и можно простенько написать свои заменители (передавая массив вторым параметром, например). Запросы действительно не придёться повторять. Программисту хорошо. Но кому-то от "select *" плохо (хостеру, админу и бедненькой базе ). А если не только в методе указываем where (параметром), но и select, то не такие уж и неповторяющиеся запросы. То есть "миф о неповторяющихся запросах". Если есть customQuery(), то никакой абстракции всё-таки не будет. Про восемь часов это кривой сарказм. Просто искренне хочется посмотреть за какое кол-во чистого времени (без вёрстки и прочих муторных вещей связаных с дизайном "лицевой" части) можно сделать блог. Если бы писал с нуля, то за ночь. Если со своим стандартным набором, то за час-два. За сколько бы получалось используя твой набор. (ещё я пользовал Джангу, Турбоджир и Кейк; на них получалось за пару дней [если не следовать скринкасту/доку "делаем блог за n минут"] , паралельно знакомясь). ~0.018 PHP: $time = explode (' ', microtime()); $star = $time[1] + $time[0]; for ($i = 0; $i <= 10000; $i++) echo $i.'<br />'; $time = explode (' ', microtime()); $stop = $time[1] + $time[0]; echo round(($stop - $star), 5); ~0.276 PHP: $time = explode (' ', microtime()); $star = $time[1] + $time[0]; for ($i = 0; $i <= 10000; $i++) eval('echo $i.\'<br />\'';); $time = explode (' ', microtime()); $stop = $time[1] + $time[0]; echo round(($stop - $star), 5); Это показывает что чем чаще вызывается eval() тем тормознее. При работе с фреймворком уменьшаться кол-во строк не будет и вызовы eval`и продолжат рости, а производительность падать. У Питона (тем более с psyco, в связке они порой быстрее C++) такого не было бы. (упомянул умные слова в отместку на "опкод-кеша", я не знаю что это такое . Часто опкод-кэш на обычные хостинги ставят?) dark-demon, после этого видео многие фреймворки сделали подобные скринкасты.
lexa, ещё как ставят он неслабо ускоряет обработку скриптов. в шестом пхп вроде обещали реализовать встроенный опкод-кэш.