Люди! Кто строил большие динамические сайты? Был бы очень благодарен за практический совет по организации фаилов, папок, классов, объектов. Что бы потом не запутаться в дебрях своих же скриптов и фаилов!
Ведь, я думаю, есть же какая-то стандартная модель поведения в подобных случаях.
Пасиба!

Стандартной модели нет. Каждый делает так, как ему удобно.

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

Поделюсь моим скромным опытом, сейчас доделываю сайт:
Стараюсь делать так, чтобы с помощью минимума усилий сделать максиму изменений, т.е. есть опр. файл, где функции, и файл с ссылками в виде массива для каждого типа ссылок:гостевая, статьи, downloads и т.д. Делаю на шаблонах. У меня есть самый главный скрипт index.php, ему мы передаем параметры вида index.php?view=guestbook, а дальше скрипт смотрит, если в папки Modules есть guestbook.php, то делает include. И вот этот главный скрипт генерирует ссылки, вверхний вид, а сам файл guestbook.php выводит все, что нужно в центр страницы. И что удобно, не надо править index.php, а просто создаешь новый модуль в папке modules, меняешь файлы с настройками, а index.php уже сам подключает этот модуль.

Это сообщение отредактировал(а) Dr.Death - 3.12.2003, 13:46

Dr.Death
совсем недавно нашел гениальный выход из проблемы модульности и единости всего портала
вплоть до поддоменности и модульности админ панели ;)
значит так,
делается два файла (а мона и больше)
start.inc - где скажем, коннект к БД, инклуд функции, логина и т.д.
out.inc - где подгружается шаблон главной страницы (или той что скажем в какойто глоб переменной - оверран так сказать), глоб.меню, и выводится на вывод....

и сам модуль:
index.php:

Код

<?php include start.inc; $content="<center>Hello, world</center>"; $global_nav="Майн пага"; //типа строчка навигации для этой страницы $title.=" - Главная";//типа была у нас заголовка "Супер сайт" а теперь.... include out.inc; //который всю эту бодягу и выведет как надо ?>

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

Master

Цитата

смотриш на скрипты и не вериш, как же я мог такую охиней понаписать

да уж, PHP тем и хорош, что одну и ту же задачу, через месяц решает легче и изящнее раз в 5, и думаешь: шож я дурак раньше такой бред понаписалто, когда тут раз и два! ;))

Я делаю следующим образом:
config.inc - загоняю глобальные переменные
start.inc - конектимся к бд, проверяем статусы, вносим изменения в статистику,...
stop.inc - закрываем конект, пишим логи,...
do/<name>.inc - все процедуры для данного действия
sh/<name>.inc - весь html (не люблю шаблоны)
index.php -
инклудим config.inc, start.inc,
через switch-case конектим "/do/<name>.inc","/sh/<name>.inc" запускаем нужную функцию,
инклудим stop.inc

Цитата

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

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

Tamerlann

Цитата

нехороший тон

хе ) нехороший тон, это когда вывод во всех модулях без разбору, а то только в одном!...и ты знаешь где что менять, что за что отвечает....

Цитата

Вывод должен быть в основном файле, без всяких процедур

обзови out.inc основным (и там нет процедур)....вот и все ;)
зы: если что, то сдается мне, что и я эту структуру не первый предложил ;)
в этом форуме до нельзя похожая структура...

Все эти многочисленные извращения с ?view=guestbook происходят от неумения программировать, совмещенного с незнанием используемых инструментов. Модель и для этого, и для всего остального давно есть, называется ООП. Не делай "инклудов", делай _классы_. Иерархии классов. У меня, например, есть такие вещи, как page.class.php, form.class.php, list.class.php и так далее (надеюсь, назначение не надо объяснять). Откуда наследуется все остальное. Для каждого конкретного сайта наследуем от абстрактной страницы уже конкретную с базовым дизайном сайта. От нее - остальные страницы сайта, тоже иерархично. Например, делаем adminpage.class.php, которая логинит пользователя, если не залогинен. От неё - все админские страницы. И т.д. (в общем, садимся и изучаем ООП). Для человеко-понятных URL делаем 404 скрипт, который и выбирает класс. _Только он и выводит что-либо пользователю_, используя методы подключенного согласно URL класса. Во всех остальных файлах есть только _классы_, у которых есть соответствующий метод вывода, вызываемый в 404. Для ввода данных делаем классы, которые отрабатывают непосредственно, без 404, но опять же ничего юзеру не выводят, а перебрасывают его (location: ) куда надо дальше. По поводу шаблонов... Поборникам smarty и прочих плацебо для чайников - читать популярные статьи на spectator.ru.
Вот примерно так. Создание страниц начинает походить на конструирование форм в MS Access: вот сюда combobox.control, а здесь db.list...

akul
а что в ?view=guestbook нехорошего. При чем здесь умение или не умение?
у меня полным полно страниц и разделов на таких вот элементах.

Использую уже проверенную и отлаженную систему "класс+шаблон":

- сайт логически делится на компоненты (или блоки - как кому нравится)
- каждый компонент пишется в отдельном PHP-филесе в виде класса с тремя функциями: конструктор (устанавливает все установки по дефолту), "Input($vars)" - где $vars принимает $_GET и $_POST, "Output()" - которая вызывается после всех Input'ов каждого компонента и отвечает за передачу переменных в шаблон; в классе "виден" родительский компонент и дочерние; дочерние "вставляются" в переменные-слоты из конструктора компонента-родителя.
- каждому компоненту соответствует свой template-файл (aka шаблон), в котором "видны" переменные именно этого компонента (а также переменные т.н. storer-а, некоего глобального объекта-хранилища), и расставлены переменные-слоты для указания, в какое место вставить сгенеренный HTML того или иного дочернего компонента. Шаблоны используются Smarty 2: весь HTML лежит в шаблоне, связь с PHP - через конструкции в фигурных скобках (можно вставлять переменные, проверять условия, выполнять циклы, вставлять готовые HTML-элементы)

Фичи:
- "прозрачное" сохранение внутренних переменных компонента ($this->vars) с пом. сессий или Cookies (по выбору)
- простая и гибкая система манипулирования компонентами (любой компонент может найти любой компонент по имени слота или public-имени, любой комп. может удалить самого себя из родителя, добавить любого компонента в родитель или в себя, и т.д.

Система наращиваемая, и очень удобная - нужно вести всего 2 папки - templates и classes/components; сборка страниц идет так, что достаточно объявить всего 1-2 страницы (типа index.php, admin.php) с содержанием типа:

Цитата

<?php require_once ("inc/main.inc.php"); $page = new CPageMain; $page->Execute(); ?>

и далее - по иерархии:
1) CPageMain создает CHeader, CLeftBar, CMainContent и CFooter
2) CLeftBar создает CTopMenu, CBanners, CGolosovanie
3) CMainContent создает CMainContentHeader, CStdTable и заполняет таблицу
и т.д.

(если кому-нибудь будет что-нибудь интересно -- выложу где-нибудь исходники. система уже давно действует на нескольких сайтах)

to akul, насчет специального языка для шаблонов -- ведь нельзя зажарить яичницу не разбив яйцо

Верстальщику и не нужно учить язык шаблонов, достаточно "воткнуть" в то или иное место template-а имя переменной в фигурных скобках, которое ему скажет программер PHP. Это потом, когда верстальщику станет мало простых средств - он захочет циклы, условия и т.п.

А если верстальщик (или дизайнер) ведет сайт через веб-интерфейс? Давать ему доступ к самому сокровенному?? Да проще и безопасней разрешить ему редактировать шаблоны, и всё на этом, для дизайна достаточно; а оплату через AuthNet мы ему показывать не будем

Если уж говорить о шаблонизаторах, то уже давно пользую вариант с апачевыми AddHandler и Action, когда фаил с определенным расширением передается на обработку PHP скрипту. В итоге имеем полностью прозрачный шаблонизатор + сессинный движок + инклюд всех необходимых функций + все необходимые заголовки

mr.DUDA Я по такому принципу форум пишу

Цитата(MuToGeN @ 5.12.2003, 01:38)

Если уж говорить о шаблонизаторах, то уже давно пользую вариант с апачевыми AddHandler и Action, когда фаил с определенным расширением передается на обработку PHP скрипту. В итоге имеем полностью прозрачный шаблонизатор + сессинный движок + инклюд всех необходимых функций + все необходимые заголовки

У меня была такая идея.
Сделать сайт на XML
индексами дирикторий сделать XML файлы, и передавать их имена на обработку PHP скрипту, который будет подставлять нужный файл под xsl шаблон!

но в связи с моим опытом работы с xml идея благополучно отправлена в to do

Не... У меня без xml и xsl, просто текстовые фаилы.
Еще когда-то что-то типа этого мастерил с mod_rewrite

Master

Цитата

смотриш на скрипты и не вериш, как же я мог такую охиней понаписать

Цитата

да уж, PHP тем и хорош, что одну и ту же задачу, через месяц решает легче и изящнее раз в 5, и думаешь: шож я дурак раньше такой бред понаписалто, когда тут раз и два! ;))

Полностью согласен ... у меня бывает что я почти все сделав переделываю заново поняв насколько проще можно было бы сделать ))

Цитата(Master @ 4.12.2003, 17:39)

akul а что в ?view=guestbook нехорошего. При чем здесь умение или не умение? у меня полным полно страниц и разделов на таких вот элементах.

чем плохи сами урли такого вида сами по себе, писано-переписано, начиная с трудолюбивого Лебедева и кончая сотней форумов. А для меня это просто показатель, что используется плохой (дыры, которые _надо затыкать_) и ненадежный (надо вручную таскать параметры через URL) принцип. Кстати, туда же - файлы .inc (тоже кто-то советовал..). Достаточно десяти минут, чтобы найти в инете кучку сайтов, базу которых можно вскрыть только потому, что у них файлы .inc называются. Т.е. если кто-то называет файлы .inc - я вижу, что человек ещё чайник. Естественно, надо запретить это в апаче, вынести за корень.... но это все - затыкание дыры, которую мы сами создали, когда надо было сразу .inc.php. Надеюсь, объяснил.

Цитата

to akul, насчет специального языка для шаблонов -- ведь нельзя зажарить яичницу не разбив яйцо

Тут важно понять, что делить надо не "дизайн от программы", а декларативные и процедурные описания. Это в общем. Шаблоны в общем случае эту задачу не решают и решить не могут. Но то, что они делают, прекрасно делает тот же include "кусок дизайна.html" в нужном месте метода класса компонента.
А имя переменной {в фигурных скобках} ничем не лучше <?=таких скобок?> с точки зрения понятности дизайнеру. А хуже тем, что добавляет совершенно лишний промежуточный слой с дополнительными глюками и тормозами.
И заметьте - когда верстальщику "станет мало" и раз уж он взялся изучать процедурные конструкции, ничто не мешает ему сразу изучить <? for(...) ?> вместо доморощенных шаблонных аналогов со своим синтаксисом.

Цитата

А если верстальщик (или дизайнер) ведет сайт через веб-интерфейс? Давать ему доступ к самому сокровенному??

Давать ему доступ к частям дизайна, включаемым внужных местах. Всё это делается в рамках ООП. Иллюстрация самого простого способа :

<? require_once 'page.class.php';

class SitePage extends Page
{
function PrintHeader($args){?>

дизайн-дизайн-дизайн

<?}
function PrintFooter($args){?>

дизайн-дизайн-дизайн

<?}}?>

Цитата

чем плохи сами урли такого вида сами по себе, писано-переписано, начиная с трудолюбивого Лебедева и кончая сотней форумов. А для меня это просто показатель, что используется плохой (дыры, которые _надо затыкать_) и ненадежный (надо вручную таскать параметры через URL) принцип. Кстати, туда же - файлы .inc (тоже кто-то советовал..).

Чем же это он такой плохой и ненадежный, можно узнать?:?

Ясное дело, что файлы называются:
my_file.class.php
или
my_file.inc.php

Минус ООП - дольше работает

Цитата(Secandr @ 5.12.2003, 16:44)

Ясное дело, что файлы называются: my_file.class.php или my_file.inc.php Минус ООП - дольше работает

ну, что касается PHP - может быть.. В общем случае неверно, всё как раз наоборот. Компилятор, имея куда больше информации о данных, можут гораздо лучше оптимизировать код. Оверхед обычно возникает оттого, что с использованием ООП мы можем делать вещи, о которых без оного только мечтали, сооответственно типична стельба из пушки по воробьям. Но это не свойство ООП, а особенность психологии. Это о компьютере. Что касается программиста, то ООП не просто ускоряет, а кардинально ускоряет работу.

Цитата(Dr @ 5.12.2003, 15:52)

Чем же это он такой плохой и ненадежный, можно узнать?:?

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

Цитата

akul> ненадежный(надо вручную таскать параметры через URL)

Я что-то не понимаю, ненадежность - это значит, что не надо параметры вручную через URL таскать?
P.S.

Цитата

чем плохи сами урли такого вида сами по себе, писано-переписано, начиная с трудолюбивого Лебедева и кончая сотней форумов

Кинь ссылку, я хочу просветиться.

Цитата

Давать ему доступ к частям дизайна, включаемым внужных местах. Всё это делается в рамках ООП. Иллюстрация самого простого способа : <? require_once 'page.class.php'; class SitePage extends Page { function PrintHeader($args){?> дизайн-дизайн-дизайн <?} function PrintFooter($args){?> дизайн-дизайн-дизайн <?}}?>

Не-ет, это же значит сунуть голову в микроволновку!
Так мы дадим возможность любому человеку, с доступом к админовской странице, сделать всё что угодно - начиная от закачки произвольного файла на наш сервер, заканчивая установкой скрипта-фильтра всех входящих и исходящих GET/POST -- что например для магазина равносильно смертному приговору с судебными разбирательствами.

Чем хорош "слоёный пирог" из Smarty/ООП - это тем, что каждый слой занимается только своим делом, и не имеет доступа к базовым функциям другого слоя. Так, наш дизайнер никогда не сможет сделать ни шага влево, ни шага вправо от HTML/TPL (не дадим мы ему PHP, и всё тут), и вместе с тем у него в руках будет вся мощь языка PHP, спрятанная на более низком слое/уровне (где работает программер). Вот в чем соль template-подхода.

akul>> в том и дело. PHP - не компилятор
И ООП в нём реализовано не лучшим образом. Насколько я помню историю пхп, он первоночально создавался без поддержки ооп, затем ооп притянули за уши к пхп.

Цитата(Dr @ 5.12.2003, 17:40)

Кинь ссылку, я хочу просветиться.

статьи, хорошие своей популярностью:
http://spectator.ru/technology/php/easy_templates
http://spectator.ru/technology/php/user_friendly_urls

Цитата(mr @ 5.12.2003, 22:00)

Не-ет, это же значит сунуть голову в микроволновку! Так мы дадим возможность любому человеку, с доступом к админовской странице, сделать всё что угодно - начиная от закачки произвольного файла на наш сервер, заканчивая установкой скрипта-фильтра всех входящих и исходящих GET/POST -- что например для магазина равносильно смертному приговору с судебными разбирательствами. Чем хорош "слоёный пирог" из Smarty/ООП - это тем, что каждый слой занимается только своим делом, и не имеет доступа к базовым функциям другого слоя. Так, наш дизайнер никогда не сможет сделать ни шага влево, ни шага вправо от HTML/TPL (не дадим мы ему PHP, и всё тут), и вместе с тем у него в руках будет вся мощь языка PHP, спрятанная на более низком слое/уровне (где работает программер). Вот в чем соль template-подхода.

Прежде всего нам надо хорошо подумать, что и от кого мы защищаем. Итак, чайник дизайнер, не способный запрограммировать цикл, у нас превратился в злобного хакера, способного обойти safe mode и нафигачить нам гадостей на сайте. Ну что тут сказать? 1. Уверяю тебя, что шаблоны не являются панацеей от этого, и "вся мощь PHP" в руках дизайнера и "безопасность сайта" - вещи взаимоисключающие, сколько бы там слоев не прокладывали. 2. Приведённый кусок - только иллюстрация, где я не рассматривал вопросы защиты сайта от кого-бы-то-ни-было. Вопросы защиты в простейшем случае "разрешаем ему в дизайн переменные вставлять" решаются одним оператором типа:

if(preg_match("/<"."\\?[^=]/",$template)) trigger_error("Обломись!",E_USER_ERROR);
(Обращаю внимание, что это тоже _иллюстрация_. Это обходится, но я не собираюсь тут "Enterpise ready" движок сайта эпистолярничать. Я только показываю направление.)

akul ну ты прям у нас белая ворона...
Во первых я не понимаю.... как ты будеш искать дыры в скриптах для работы которых требуются GET параметры...
также для меня загадка где Лебедев про такое писал.

ну ООП для скрипта, который выполняется всего 0.2 - 0.3 секунды это круто, конечно....
зы: хотя я может чего и не понимаю, но серверные скрипты, это же как раньше под Дос проги были - запустили, прогналось, вывелось...и все....а ООП очень полезно в винде....но никак не в PHP

Цитата(Master @ 8.12.2003, 14:23)

akul ну ты прям у нас белая ворона... Во первых я не понимаю.... как ты будеш искать дыры в скриптах для работы которых требуются GET параметры... также для меня загадка где Лебедев про такое писал.

Если уж речь зашла о том, как это делаю я - я не ищу там дыры. Я их просто не делаю. Во-первых, после двадцати лет программирования вопрос о том, идиотизм ли передавать параметры как глобальные переменные, уже не возникает. Поэтому сразу была написана функция "низкого уровня" get_args(), которая:
1. Абстрагирует нас от метода передачи параметров (GET/POST)
2. Является более-менее переносимой между серверами (чего нельзя сказать _ни об одном способе_, предлагаемом PHP)
3. Попутно чистит прочий идиотизм (magic_quotes_gps), не дающий нам писать переносимый код.
На выходе мы получаем гарантированный и чистый от квотинга массив параметров.
Отсюда уже можно брать данные и как-то их использовать, но это почти не требуется, так как я не использую способов, с которых и началась эта ветка. В большинстве же случаев передаваемые данные были получены из какой-то формы. А форма - это объект. Содержащий массив других объектов - контролов. И _всё_ взаимодействие с данными идет через их интерфейсы. Для каждого контрола, кроме параметров внешнего вида, есть параметры данных (маска данных, обработчик изменения, связанное поле таблицы, если форма связана с рекордсетом и т.д.), и, беря какой-нибудь $myForm->Control['Email']->Value, мы имеем уже проверенный емейл. В общем, кто в конструкторах форм во всяких MS Access работал, поймет. А библиотека используется уже много лет и, может, не очень красива логически (сейчас я бы многое переделал), но дырки в ней искать уже тяжело. Сначала была просто Forms (сохранение состояния, валидация данных на обеих сторонах, свои типы контролов...), потом всякие dbForms (связанная с базой данных), потом oodbForm (связанная с объектной базой..).. И делаются такие вещи добавление пары методов, без переделки старого кода. Вот зачем нужен ООП.
Еще раз о дизайнерах. На самом деле "защищать" сайт от дизайнера не нужно совсем по другой причине. Можете считать меня экстремистом, но дизайнер не должен знать никакого HMTL кода. Пускай сидит и дизайнит в своем фотошопе, а HTML кодирование - это кодирование, и заниматься им должен именно HTML-кодер, т.е. HTML-программист. Результат получше будет, однако.

Цитата(Master @ 8.12.2003, 14:23)

также для меня загадка где Лебедев про такое писал.

где-то в параграфах.

to mr.DUDA

Цитата

(если кому-нибудь будет что-нибудь интересно -- выложу где-нибудь исходники. система уже давно действует на нескольких сайтах)

Было бы неплохо: лучше раз увидеть

to pavlik,

кинь мне на [email protected] свой e-mail, я солью тебе все исходники.

Понадобиться включенный mod_rewrite на сервере apache, для "правильных" URL, отражающих иерархическую структуру страницы

index.php
->congif.inc.php - содержит конфигурацию, данные для DB-connect
->include/startup.inc.php - содержит include's для предзагрузки, в частности библиотеку определения функций БД, для указанной в конфигурации и файл языка интерфейса, роме того здесь разбирается текущий маршрут в массив $argv

По текущему URL вычисляется ID страницы в БД, подымаем контент этой страницы, из него формируем XML.
Например,
<root>
<tree>
<treeitem>
<label>Главная</label>
</treeitem>
</tree>

<doc>
<title>мета-Заголовок</title>
<header>Заголовок</header>
<content1>Содержание</content1>
</doc>

В БД также храниться имя файла XSTL для описания правил отображения данной страницы.

Нам останоль послать header XML-заголовок, и на вывод подать сформированный XML

Master

Цитата

также для меня загадка где Лебедев про такое писал.

http://www.artlebedev.ru/kovodstvo2/sections/48/