есть идея движка сайта, требуется критика

[xelos]

в общем делаю сайтик на php, mysql.
сайт состоит из нескольких рубрик, которые выбираются из меню.
Необходимо, чтобы меню и содержимое страниц можно было менять просто. Раньше такие вещи я делал через одну страницу, которая отвечала за форму и дизайн, и в которой вызывались модули с контекстом (с содержимым). Структура сайта частично хранилась в MySql (и все проверки на правильность вызова делались через бд). Чтобы добавить меню и страницу, ессно, требовалось изменение в бд.
Чувак, которому пишу сайт сейчас, не хочет такой системы. Хочет сам делать странички с содержимым и загружать их на сайт.
Откуда появилась следующая идея.
Структура сайта будет соответствовать физическому расположению файлов на диске. Поясняю. Для создания меню использовать, например, каталог Menu на диске. Каждый подкаталог этого каталога будет соответствовать одной кнопке меню. Страницы соответствующие пунктам меню находятся там же. Получается, что каждая страница может редактироваться независимо и при загрузке на сайт, все будет автоматически обновляться.

поскоку делается все на php, то получается что при каждой загрузке страницы php будет работать с диском, вот и вопрос возникает насколько такая идея будет работоспособна и по быстроте вроде как сомнения возникают...

[Finch]

Это конечно одно из решений. Но при каждом запросе перебирать все каталоги, это как-то долговато. Лучше остановится на решении с базой. Просто улучшить админку. Так чтобы твоему заказчику ненадо было бы задумываться и копаться во внутреностях сайта.

[Dimka]

Во-первых, я думаю, что не при каждом запросе, а достаточно лишь при открытии сессии - т.е. при первом запуске. Ну а позаботиться о том, чтобы юзер не скучал, можно придумать как.

Во-вторых, можно грузить не всё меню - не все разветвления дерева, а лишь то, что нужно по мере потребностей - из области "ленивых вычислений".

В-третьих, в каждом каталоге, наверно, стоит завести какой-нибудь description-файл txt, ini или даже xml.

В-четвёртых, админку ведь надо писать (если не идти по пути готовых шаблонов).

А мысль интересная. Вопрос лишь в нагрузке сайта. Если не предполагается дикой популярности и особо крупных размеров сайта, то проблем с производительностью, наверно, не будет.

[xelos]

dimka,  я в том же направлении думаю.

меню грузить один раз тока через сессию. а само меню одноуровневое, так что считывать придется только одну директорию. первые опыты меня удовлетворяют - задал шаблон для index.php в каждой директории меню и вызываю из него файл с контекстом... у файла с контекстом одно ограничение - имя (чтоб index.php не править), а сформирован он может быть как угодно... осталось потестить на нагрузку - не могу придумать как.

[Dracul]

а как насчет того, что бы узнать время, которое было в начле выполнения сценария и в конце....
и посмотреть как сильно генерация меню тормозит выполнение сценария...

[RXL]

Я думаю, если у тебя файлов там не сотни, то работать будет быстро: спасет кеширование файловой системы.

Для тестирования нужно сделать параллельно с десяток-другой запросов. В программе вычисляй время исполнения.

[Люсь]

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

[Dimka]

Ну хотя бы потому, что база - это один файл. Далее, СУБД специально приспособлена для быстрого выполнения операций поиска и выборки данных. При обработке ветвистого файлового дерева, структура которого нигде отдельно не описана (проиндексирована), возможны лишь последовательные операции чтения узлов. Операции эти происходят не в памяти, а с диском, а это на порядки медленнее. Разве что дисковой кэш спасёт, но не при первом обращении. СУБД, конечно, нагружает процессор и память больше, чем операции с файлами, но в соотнесении с производительностью выгоднее СУБД.

[PooH]

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

[xelos]

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

можно и так, написать отдельный скрипт, который сканирует каталог и помещает структуру в базу. Можно обойтись и без инишек. просто после добавления страниц в каталог на сервер, запускать в обязательном порядке скрипт... так мне даже больше нравится, можно отдельно 2 скрипта написать - для тестирования новых рубрик и окончательную версию.

[Chuda]

всё вышевысказанное приемлемо ТОЛЬКО в том случае, если у сайта будет малая посещаемость, м развиваться он не будет.
но будет ли такое писать уважающий себя вебмастер?
вопрос риторический. конечно же нет.
а уж если заказчик хочет сам писать страницы, то предоставь ему такую возможность - напиши админ-интерфейс. и пусть в нём будет возможность загружать написанные самостоятельно страницы и указывать место этой страницы в структуре сайта, пункт меню и всё такое прочее.
неужели сложно написать страницу из одного поля ввода для текста страницы и минимальный интерфейс для интеграции в структуру? а обрабатывать отправленные с этой страницы данные пусть будет тот самый "запускаемый в обязательном порядке скрипт".
можно, конечно, ещё сделать собственный парсер, проверяющий корректность загружаемой страницы, но это уже вопрос творческого подхода и профессиональной гордости.
кстати, о профессиональной гордости.
а она позволяет халтурить?

[PooH]

Chuda, читай в первом посте:

Необходимо, чтобы меню и содержимое страниц можно было менять просто. Раньше такие вещи я делал через одну страницу, которая отвечала за форму и дизайн, и в которой вызывались модули с контекстом (с содержимым). Структура сайта частично хранилась в MySql (и все проверки на правильность вызова делались через бд). Чтобы добавить меню и страницу, ессно, требовалось изменение в бд.
Чувак, которому пишу сайт сейчас, не хочет такой системы.

[Chuda]

Чувак, которому пишу сайт сейчас, не хочет такой системы.

[/quote]

замечательно.
а разве я предлагаю такую систему?
судя по описанию ситуации заказчик - воинствующий ламер. поправьте меня, если не так.
и создать ему админку, через которую он сможет закачивать собственноручно написанные файлы.
а если у человека всё же вместо кочана капусты голова с мозгами, то скорее всего он вменяем.

[xelos]

Чувак, которому пишу сайт сейчас, не хочет такой системы.

замечательно.
а разве я предлагаю такую систему?
судя по описанию ситуации заказчик - воинствующий ламер. поправьте меня, если не так.
и создать ему админку, через которую он сможет закачивать собственноручно написанные файлы.
а если у человека всё же вместо кочана капусты голова с мозгами, то скорее всего он вменяем.

давай идеи, страницы с картинками и со скриптами, все это в бд хранить? и админку делать для загрузки 10 файлов одной страницы? и для одного пункта меню если несколько страниц, с движением "вперед/назад" можно, конечно...
 к тому ж, почитай последние посты. в итоге все будет организовано через бд. только структура сайта будет определяться физической структурой файлов.
ЧИТАЙТЕ ВНИМАТЕЛЬНЕЕ!!!

P.S. что убивает, так это то, что, все следуют общепринятым шаблонам. и не хотят от них отходить. Это уже, конечно уровень не программиста, а архитектора системы, но все равно, у программиста тоже должна голова работать в этом направлении, ИМХО.

[Dimka]

судя по описанию ситуации заказчик - воинствующий ламер.
а если у человека всё же вместо кочана капусты голова с мозгами, то скорее всего он вменяем.

Судя по этим словам, ты о себе говоришь.

всё вышевысказанное приемлемо ТОЛЬКО в том случае, если у сайта будет малая посещаемость, м развиваться он не будет.
но будет ли такое писать уважающий себя вебмастер?

Странно, что нужно объяснять простые вещи. Выполнение заказов - это не средство демонстрации своей крутизны, а наиболее эффективное удовлетворение нужд заказчика с минимальными издержками при оговоренном качестве.

Писать мегадвижок для 2-10 страничек - это "из пушки по воробьям" и может быть экономически нецелесообразно. Не каждый сайт служит для "раскрутки" и заработка.

P.S. Сдаётся мне, что до звания "вебмастер" тебе ещё далековато. "Вебподмастерье" может быть.

[Chuda]

ладно, хорошо.
сайт из 10 страниц и развиваться не собирается.
заказчик хочет самостоятельно писать страницы.
тогда давайте вспомним про SSI. на мой взгляд в таком случае более применимо.
и давайте усомнимся в необходимости автоматической генерации меню.

[xelos]

условие такое, чтобы добавить при случае можно было пункт в меню, со страничками дополнительными.
странички могут содержать картинки и на 1 пункт меню возможно 2-3 раздельных странички.
Также, необходимо, чтобы если что пункт убрать можно. Т.е. минимум автоматизации все же требуется.

[Chuda]

И всё же, если человек собирается самостоятельно писать странички, то значит, что он как минимум знает html.
автоматизация должна в таком случае делать что: принять название пункта меню, вписать его например в БД, установить связь этого названия с соответствующей страницей, определить положение пункта в меню.
выполнить эти действия для администратора сайта примерно одинаково по сложности как в случае правки html-кода меню, так и в случае специального интерфейса.
но если всё же делать этот самый специальный интерфейс, то логично поручить ему одновременно загрузку страницы и размещение соответствующего пункта в меню. так ведь?
или же, если заказчик считает себя достаточно продвинутым, можно ему доверить и правку кода меню.
а всяческие половинчатые меры будут производить впечатление недоделки.

[xelos]

автоматизация должна в таком случае делать что: принять название пункта меню, вписать его например в БД, установить связь этого названия с соответствующей страницей, определить положение пункта в меню.

ну так скрипт в итоге и будет это делать, почитайте пост PooH от 13 марта и мой следующий.
заказчик хочет по фтп загрузить свои страницы на сайт и чтобы это автоматически отображалось на страницах (в меню).
у меня создается впечатление что какое-то недопонимание происходит.