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

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

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

Поделюсь моим скромным опытом, сейчас доделываю сайт:
Стараюсь делать так, чтобы с помощью минимума усилий сделать максиму изменений, т.е. есть опр. файл, где функции, и файл с ссылками в виде массива для каждого типа ссылок:гостевая, статьи, 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 Я по такому принципу форум пишу