Затеял сделать собственную систему управления контентом (CMS).
Известные мне — phpwebsite, ezpublish, runuke и т.п. — не очень устраивают из-за громоздкости,
а также из-за того, что документы в них хранятся как записи в БД.
Соответственно, сопровождать их нужно через веб-интерфейс, либо через phpMyAdmin.
И пришла мне в голову затея — делать документы-сырцы, скажем, в HTML.
А движок сайта пусть извлекает из них информацию, помеченную особым образом.
К примеру <title>...</title> — это заголовок, <body>...</body> — это текст, и так далее.
В связи с этим пара вопросов
1) Не изобретаю ли я велосипед?
Можно ли где чего почитать на эту тему?
Существуют ли какие-то готовые CMS на основе html-файлов?
2) Технический вопрос
Как парсить многострочный текст?
удается только если $html не содержит CR|LF.
Пришлось воспользоваться ereg, но в документации сказано, что он медленнее. Кроме того, preg мощнее (или я заблуждаюсь)?
Во всяком случае, если я захотел вытащить все-все-все вхождения (preg_match_all), то с помощью ereg такой фокус не получится.
А разбить HTML на строки и парсить каждую по отдельности — не есть правильно: HTML-редактор может навтыкать переносы куда угодно, например, так:
<body
>.....</body>
особенно это касается <div> | <span>, которые нужно различать по их id|class.
(Оговорюсь сразу: в php я новичок, и возможно, делаю какие-то очевидные глупости. Если да — укажите),
А вообще, поищи тут по форуму preg_replace. Тут давеча много чего обсуждалось про регекспы в PHP. В частности, в некоторых моих сообщениях есть необходимые шаблоны и какое-никакое описание, как выкусить весь контент из body.
Например, в этой ветке: http://www.rsdn.ru/Forum/?mid=233630
Здравствуйте, Кодт, Вы писали:
К>Известные мне — phpwebsite, ezpublish, runuke и т.п. — не очень устраивают из-за громоздкости, К>а также из-за того, что документы в них хранятся как записи в БД.
БД — это хорошо, т.к. быстрее, удобнее в доступе и сопровождении.
К>Соответственно, сопровождать их нужно через веб-интерфейс, либо через phpMyAdmin.
А что плохого в первом?
К>2) Технический вопрос К>Как парсить многострочный текст? К>
rtfm вот тут: http://de.php.net/manual/de/pcre.pattern.modifiers.php
К>(Оговорюсь сразу: в php я новичок, и возможно, делаю какие-то очевидные глупости. Если да — укажите),
имхо тестовый цмс того не стоит. Честно говоря, так и не понял чем плохи "БД цмс"
Первый вариант — не прошел.
Второй — дал лишний элемент в $result.
На самом деле, как уже написал vamp, правильное решение — опция поиска s.
DSD>А вообще, поищи тут по форуму preg_replace. Тут давеча много чего обсуждалось про регекспы в PHP. В частности, в некоторых моих сообщениях есть необходимые шаблоны и какое-никакое описание, как выкусить весь контент из body. DSD>Например, в этой ветке: http://www.rsdn.ru/Forum/?mid=233630
Здравствуйте, Rumata, Вы писали:
К>>Известные мне — phpwebsite, ezpublish, runuke и т.п. — не очень устраивают из-за громоздкости, К>>а также из-за того, что документы в них хранятся как записи в БД. R>БД — это хорошо, т.к. быстрее, удобнее в доступе и сопровождении.
К>>Соответственно, сопровождать их нужно через веб-интерфейс, либо через phpMyAdmin. R>А что плохого в первом?
Чтобы залить статью с форматированием,
я сначала готовлю ее HTML-код в каком-нибудь редакторе (ворд, дримвивер, хомяк),
затем выдираю содержимое между <body>...</body>,
копирую в клипборд,
вставляю в текстовое поле формы публикации,
понеслась душа в рай.
И так — для каждой статьи. А если мне надо что-то поправить?
А файловый цимес выглядит так:
Я имею сайт-черновик (голые статьи без обвески), который сопровождаю тем же дримвивером.
Могу сделать массовую закачку по ftp.
При желании можно сделать автоматическую синхронизацию базы данных (например, чтобы собирать карту сайта, навигацию и новости). А можно и обойтись — просто в том же сайте-черновике держать служебные страницы, которые поправлять руками.
К>>2) Технический вопрос К>>Как парсить многострочный текст? К>>
Здравствуйте, Кодт, Вы писали:
К>На самом деле, как уже написал vamp, правильное решение — опция поиска s.
Не правильное, а одно из правильных
Не делайте себе из этого жесткое правило. Опция s — действительно воспринимает любой текст как одну строку, но она является опциональной, и присутствует не во всех движках регулярных выражений(так же, как и опция m и несколько других). А где присутствует, не всегда работает так, как хотелось бы.
Точно работает в Юникс-перле, вот выяснилось, что и в ПХП тоже... В ActivePerl я встречал какие-то грабли с этой опцией(сейчас уже не помню, что именно она делала не так). В JS RegEx'ах тоже кривость имеется...
Кстати, я бы назвал эту опцию чем-то вроде чит-кода, т.к. она противоречит некоторым правилам регекспов, к примеру нарушается правило, что "."(точка) — это любой символ кроме NewLine(\n).
Кстати, вышеупомянутые глюки были связаны именно с совместным использованием \n в выражении и опции s.
DSD>Точно работает в Юникс-перле, вот выяснилось, что и в ПХП тоже... В ActivePerl я встречал какие-то грабли с этой опцией(сейчас уже не помню, что именно она делала не так).
Постоянно пользуюсь ActiveState Perl, и в том числе поиском с этой опцией. Ни разу не
заметил никаких странностей. Не могли бы Вы привести пример? На случай, чтобы я избегал потенциальных глюков.
DSD>Кстати, я бы назвал эту опцию чем-то вроде чит-кода, т.к. она противоречит некоторым правилам регекспов, к примеру нарушается правило, что "."(точка) — это любой символ кроме NewLine(\n).
Нет. На то она и эта опция — расширять точку на символы перевода строк.
Здравствуйте, DSD, Вы писали:
R>>БД — это хорошо, т.к. быстрее, удобнее в доступе и сопровождении.
DSD>Быстрее??? Сервер БД быстрее, чем файловая система??? Не заблуждайтесь... DSD>А с остальным согласен.
В принципе, это может быть действительно быстрее:
* если одна запись = один файл, то этот файл нужно распарсивать, в то время как в записи уже поля раскиданы.
* если нужно вывести каталог чего-то-там, то выбор будет между SELECT некоторых столбцов из БД и сканированием и распарсиванием файлов в директории.
БД удобнее в доступе и сопровождении?
Тут меня обуревают сомнения. Контроль версий документов, редактирование на локальной машине...
В общем писал я парсер хтмл для пхп и даже написал. Сам тектс для разбора хранится в одной строке (не надо его разбирать построчкам). И работает медленновасто. Но вообще то для таких целей по-моему используют XML, а для него парсер в пхп уже встроен.
Здравствуйте, Ветер, Вы писали:
В>В общем писал я парсер хтмл для пхп и даже написал. Сам тектс для разбора хранится в одной строке (не надо его разбирать построчкам). И работает медленновасто. Но вообще то для таких целей по-моему используют XML, а для него парсер в пхп уже встроен.
Можно, конечно, по-простому XHTML интерпретировать как XML. Но, как я понимаю, в PHP реализован SAX, а мне скорее пригодится DOM.
В>сам парсер валяется www.fareastmotors.ru/parser/index.php
Здравствуйте, Кодт, Вы писали:
R>>>БД — это хорошо, т.к. быстрее, удобнее в доступе и сопровождении.
DSD>>Быстрее??? Сервер БД быстрее, чем файловая система??? Не заблуждайтесь... DSD>>А с остальным согласен.
К>В принципе, это может быть действительно быстрее: К>* если одна запись = один файл, то этот файл нужно распарсивать, в то время как в записи уже поля раскиданы. К>* если нужно вывести каталог чего-то-там, то выбор будет между SELECT некоторых столбцов из БД и сканированием и распарсиванием файлов в директории.
Сколько необходимо ресурсов, чтобы установить соединение с сервером БД?
Сколько кушает сервер БД при парсинге запроса?
---//--- при отборе записей и вытаскивании полей?
---//--- при упаковке и отсылке данных вашему приложению?
Сколько кушает ваше приложение(клиентский API сервера БД) при приеме данных от сервера и преобразование из протокольного потока в удобоваримую для вас структуру?
Сервер БД очень удобен при поиске и выборке данных, когда самому все это лень писать.
Ну и кеширование в нем конечно тоже немалую роль играет в определенных случаях(но не во всех).
Здравствуйте, Кодт, Вы писали:
К>>>Соответственно, сопровождать их нужно через веб-интерфейс, либо через phpMyAdmin.
К>А файловый цимес выглядит так: К>Я имею сайт-черновик (голые статьи без обвески), который сопровождаю тем же дримвивером. К>Могу сделать массовую закачку по ftp. К>При желании можно сделать автоматическую синхронизацию базы данных (например, чтобы собирать карту сайта, навигацию и новости). А можно и обойтись — просто в том же сайте-черновике держать служебные страницы, которые поправлять руками.
Не занимайся фигней. Копай в сторону шаблонов и онлайнового редактора на основе IE. Хороший редактор стоит денег, но есть демки, из которых можно все выцепить. Вот например отсюда — http://www.webedpro.com/ . Если совесть не позволяет — можешь написать сам — все достаточно просто, и описано в МСДН.
R>>имхо тестовый цмс того не стоит. Честно говоря, так и не понял чем плохи "БД цмс" К>Трудоемкостью редактирования материала.
Еще раз : копай в сторону онлайнового редактора.
Здравствуйте, lozzy, Вы писали:
L>Не занимайся фигней. Копай в сторону шаблонов и онлайнового редактора на основе IE. Хороший редактор стоит денег, но есть демки, из которых можно все выцепить. Вот например отсюда — http://www.webedpro.com/ . Если совесть не позволяет — можешь написать сам — все достаточно просто, и описано в МСДН.
Насчет фигни, тут я бы поспорил.
Берем готовый цимес, тот же ruNuke или phpWebsite,
там есть какие-то требования к вводу материалов,
хакаем его вдоль и поперек, чтобы понять, как он устроен,
прикручиваем в нужное место свой собственный редактор (потому что встроенный — это задница),
и, как говорится, "он вокзал ее несколько долгих часов".
Очень мне это улыбается.
R>>>имхо тестовый цмс того не стоит. Честно говоря, так и не понял чем плохи "БД цмс" К>>Трудоемкостью редактирования материала. L>Еще раз : копай в сторону онлайнового редактора.
Нафиг мне это надо? Лучше я сделаю модуль upload+export html в базу данных, а редактировать буду в оффлайне, за чашкой кофэ.
Здравствуйте, Кодт, Вы писали:
К>Насчет фигни, тут я бы поспорил. К>Берем готовый цимес, тот же ruNuke или phpWebsite, К>там есть какие-то требования к вводу материалов, К>хакаем его вдоль и поперек, чтобы понять, как он устроен, К>прикручиваем в нужное место свой собственный редактор (потому что встроенный — это задница), К>и, как говорится, "он вокзал ее несколько долгих часов".
К>Очень мне это улыбается.
А в чем трабл-то ? Не виже совсем. Если сайт простой, то нафига тебе вообще эти нюки надо ?
R>>>>имхо тестовый цмс того не стоит. Честно говоря, так и не понял чем плохи "БД цмс" К>>>Трудоемкостью редактирования материала. L>>Еще раз : копай в сторону онлайнового редактора.
К>Нафиг мне это надо? Лучше я сделаю модуль upload+export html в базу данных, а редактировать буду в оффлайне, за чашкой кофэ.
Ну, если сидишь по часам, тогда оно то самое. А ежели на локалке сервак — сам бог велел онлайн делать.
Здравствуйте, DSD, Вы писали:
R>>>>БД — это хорошо, т.к. быстрее, удобнее в доступе и сопровождении.
DSD>>>Быстрее??? Сервер БД быстрее, чем файловая система??? Не заблуждайтесь... DSD>>>А с остальным согласен.
К>>В принципе, это может быть действительно быстрее: К>>* если одна запись = один файл, то этот файл нужно распарсивать, в то время как в записи уже поля раскиданы. К>>* если нужно вывести каталог чего-то-там, то выбор будет между SELECT некоторых столбцов из БД и сканированием и распарсиванием файлов в директории. DSD>Сколько необходимо ресурсов, чтобы установить соединение с сервером БД? DSD>Сколько кушает сервер БД при парсинге запроса? DSD>---//--- при отборе записей и вытаскивании полей? DSD>---//--- при упаковке и отсылке данных вашему приложению? DSD>Сколько кушает ваше приложение(клиентский API сервера БД) при приеме данных от сервера и преобразование из протокольного потока в удобоваримую для вас структуру?
Не согласен. Ресурсов нужно имхо значительно меньше, чем для обращения к файловой стистеме. Спор безосновательный (на каждое Ваше утверждение могу предлоить контрдовод). Нуже бенчмарк. Неопнятно только, как его организовать.
btw по поводу сопровождения: бд сопровождать гораздо удобнее, если есть правильные инструменты для этого.
Здравствуйте, Rumata, Вы писали:
DSD>>Сколько необходимо ресурсов, чтобы установить соединение с сервером БД? DSD>>Сколько кушает сервер БД при парсинге запроса? DSD>>---//--- при отборе записей и вытаскивании полей? DSD>>---//--- при упаковке и отсылке данных вашему приложению? DSD>>Сколько кушает ваше приложение(клиентский API сервера БД) при приеме данных от сервера и преобразование из протокольного потока в удобоваримую для вас структуру?
R>Не согласен. Ресурсов нужно имхо значительно меньше, чем для обращения к файловой стистеме. Спор безосновательный (на каждое Ваше утверждение могу предлоить контрдовод). Нуже бенчмарк. Неопнятно только, как его организовать.
То есть, по вашему мнению, сервер БД к файловой системе не обращается, так?
Так вот, спешу вас разочаровать, он и к fs обращается, и все вышеперечисленное делает. И как я сказал, чуть снижается ресурсопотребление только за счет некоторого кеширования данных.
Что же касается хранения данных в своем формате и работы с ними, то тут быстродействие большей частью зависит от того, на каком языке вы программируете данное приложение. Ясен пень, что сервера БД пишутся чаще всего на чистом С или С++.
Даже если писать на том же Перле или PHP, многое зависит от того, какие функции использует программист.
К примеру, здесь на форуме многие сами используют и пытаются другим советовать функции типа get_file_contents или что-то вроде того, мол типа такая крутая функция, одним вызовом можно получить любой файл, локальный, сетевой или вообще по URL. Но никто не задумывается, что единственное преимущество этой функции — это ее универсальность, т.е. удобство делать все и в разных ситуациях одним вызовом. Зато при этом в каждом локальном случае эта функция делает туеву хучу разной ненужной работы, как то парсинг аргумента, чтобы получить представление о местоположении файла(локал, сеть, инет), выделение в памяти буффера под содержимое(хотя далеко не всегда нужен весь контент файла), ну и т.п. Плюс ко всему, возможно с локальными файлами она внутри себя работает в текстовом режиме, что в таком случае тоже сказывается на ее производительности.
Ясен пень, тут будут тормоза.
R>btw по поводу сопровождения: бд сопровождать гораздо удобнее, если есть правильные инструменты для этого.
С этим не спорю. Однако иногда и тут бывают грабли. Нет ничего идеального
Исходниками поделюсь я их на сайтик выкину сегодня завтра. Правда я его не полировал особо, т.к. еще не закончил. Парсить то он парсит, даже объектную модель строит, единственный трабл — медленно, поэтому для моих целей малоприменим оказался. Мине надо большие таблицы, да еще и с кривым кодом разбирать, а это занимает более 30 секунд, ну и сервак его выкидывает. Так что эту версию я особо полировать и не стал, а вот слегонца переделывать придется. Как тока выложу, сразу скажу.
Здравствуйте, Rumata, Вы писали:
R>Не согласен. Ресурсов нужно имхо значительно меньше, чем для обращения к файловой стистеме. Спор безосновательный (на каждое Ваше утверждение могу предлоить контрдовод). Нуже бенчмарк. Неопнятно только, как его организовать.
R>btw по поводу сопровождения: бд сопровождать гораздо удобнее, если есть правильные инструменты для этого.