опять мутный вопрос

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

функционал для каждого модуля находится в этом самом модуле и выдаёт он хтмл взависимости от существующих переменных

если принять за правило, что все вычисления и запросы должны осуществиться до посылки заголовков, то получается надо вводить некую переменную, в которую дособирать весь хтмл из модулей $html .= '<тэги>'; и вывод только в конце (а ведь он может быть достаточно большим - 200-400 кб, или это ничего?)
создавать хередок или шаблоны (делал только под спецзадачи) как-то не вижу смысла, т.к. получается надо довести все переменные до конца, вызвать все эти шаблоны и пихать


не хотелось бы, чтоб меня отсылали к теории по шаблонам (итак каша в голове от многочисл.документации), что вообще считаете, как лучше произвести вывод в таком случае?

спасибо

Ты, наверное, хотел сказать не "страницу", а "шаблон"?

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

Я вижу несколько выходов.
Первый - это банальный. Перехватить выходной поток командой obstart(), и, пока всё не обработается, не выводить в браузер. Но при этом у тебя теряется одно из немаловажных преимуществ HTM - отображение страницы "налету", то есть пока все данные не обработаются, пользователь ничего не увидит. Можно, конечно, перехватывать не всю инфу, а только какую-то часть кода, а потом комбинировать командой ob_get_clean(), но всё-равно это не самый лучший способ, как по мне.

Второй способ понагляднее. Есть такая модель, MVC называется (Model View Controller). Там есть одна точка входа, т.е. не 10 скриптов типа index.php, shop.php, guestbook.php, а один единственный базовый скрипт index.php, который решает дальнейшую судьбу (выбирает какой из контроллеров подключить, хотя, зачастую для этой задачи создаётся дополнительный скрипт router.php, и в базовом скрипте остаётся только поключение конфига, и инициализация данных). Весь код делится на 3 логические составляющие, на какие - не сложно догадаться из названия. Все рассчёты, работа с СУБД и так далее происходят, собственно, в model (модели). View (представление), отвечает непосредственно за вывод информации. В качестве view может выступать какой-нибудь шаблонизатор. Controller (контроллеры) будут отвечать за обработку пользовательской деятельности - обрабатывают данные, полученные от пользователя ($_GET, $_POST, $_COOKIE, etc), решают, какие данные запросить у model (никаких рассчётов в контроллере особо не проводится) и выбирают, в какое из view передать обработанные данные

Про этот способ достаточно неплохо рассказано (и показано) здесь.

Стоит так же добавить, что этот способ используется в мощных фреймвёрках типа Zend Framework, mzz и т.д.

Это сообщение отредактировал(а) HackMan - 22.7.2008, 19:24

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

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

хотя итак ясно. но хочется мнение услышать

HackMan, вот только не надо сказки рассказывать. 
все эти  index.php, shop.php, guestbook.php у тебя останутся. только вызываться будут через индекс. 
Самое большое надувательство после смарти - это ваше эмвэцэ.

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

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

bars80080, 
Что-то не очень понял вопроса.

Хранить их можно как угодно. зависит от особенностей проекта и/или фреймворка. Можно создать отдельную папочку modules и в ней на каждый модуль по папке, а в каждой из той папок создать реализацию контроллера, моедли и представления данного модуля. А можно создать 
три папки: modules, controllers, views и кидать в них все модули. Однозначно лучшего варианта нет, всё зависит от потребностей. Вот была бы файловая система не иерархическая, а реляционная, было бы лучше   

Как подключать модули - тоже единого решения нет. Можно например, просканировать папку modules (для самого первого варианта) и таким образом узнать о том, какие модули есть. А можно в базе данных создать табичку modules примерно следующего содержания:

• id
• path
• name
• author

Опять же всё зависит от поставленной задачи.

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

• parent

Ещё раз повторюсь, что универсального, единственно-правильного решения не существует. У меня от проекта к проекту структура данных постоянно меняется, что-то добавляю, что-то меняю. Одни изменения оправданные, другие оправданны только в рамках данного проекта.

Добавлено @ 20:38
Feldmarschall, я не говорил, что модель должна быть одна


Я не утверждал, что скриптов станет меньше. Я сказал, что точка входа будет одна



Это сообщение отредактировал(а) HackMan - 22.7.2008, 20:41

Может, и не утверждал, но написал.

Ладно, значит остались все эти скрипты. А что тогда лежит в model?

значит или я неправильно выразился или ты меня не так понял

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

Это сообщение отредактировал(а) Feldmarschall - 22.7.2008, 20:57

Конечно существуют. Прочитай мой предыдущий пост, адресованный bars80080, только я там опечатался


Хотел написать не modules, а models



А при чём тут вообще смарти? Мой шаблонизатор сводится к



Смарти я не признаю. На смарти, пишут шаблоны на его (довольно корявом) языке, чтобы смарти их потом перегонял постоянно в PHP-код, а это куча никому не нужной работы.



Хм... Например, Wordpress, IPB если я не ошибаюсь

Это сообщение отредактировал(а) HackMan - 22.7.2008, 21:13

выше ты написал только, что универсального, единственно-правильного решения не существует.
И никакого не привел.
вот, допустим, у меня был сайт из 4 скриптов - index.php, shop.php, guestbook.php, news.php
как его переделать под MVC?

А что значит канонического?

MVC - это не более чем схема организации проекта, которая упрощает работу с ним.

Да, ты можешь это все сделать на отдельных файлах, понимать логику связей между ними будет несколько сложнее.

Добавлено через 47 секунд

А надо?

Какие между ними связи существуют? Если ни каких... то особого смысла нет.

то есть, если я работу с БД для гостевой, новостей и шопа солью в один файл, обработку гета с постом для них же - в другой, то это получится MVC, и логика связей упростится. Я правильно понял?

Добавлено через 1 минуту и 51 секунду
И еще.
если model у меня - это структура каталога - 

сами файлы - контроллеры, а вью - используемый ими Смарти, то у меня тоже MVC?

Добавлено через 3 минуты и 23 секунды
Я дофига встречаю людей, которые постоянно говорят слово MVC.
Но ни от одного я не смог добиться, что это такое, и как оно применяется в их конкретных скриптах.

Добавлено через 7 минут и 13 секунд

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

Прочти ещё чуть выше, некоторые примеры я дал   



Что-то далеко уходим от главной темы. Это понимать как проверку моих знаний?   

Навскидку я бы сделал примерно так:

• http://somehost.com/ - главная страница
• http://somehost.com/shop - магазин
• http://somehost.com/guestbook - гостевуха
• http://somehost.com/news - новости

Иерархия проекта следующая:



Это сообщение отредактировал(а) HackMan - 22.7.2008, 21:50

Нет, это будет оливье 



Не совсем верно.
Модель - это сущность. Объект которым ты оперируешь.
Например в гостевой используются две модели User и Message.
Задача модели сделать прозрачным работу с источниками данных. Т.е. тебе не нужно беспокоится что и откуда берется - ты это берешь у модели.



Честно? не очень 

А вот если добавить вывод контекстных новостей всюду. Общий один на всех контроллер для экспорта информации в PDF, CSV, XML и т.д.
Сверху навесить требование работы этого всего на ПК, КПК и к примеру touchpad.
Да скажем с 2-3мя типами принтеров (тоже общий для всех).

Вот тогда вопрос правильного структурирования кода может встать.

опять ты цепляешь к смарти...

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

Смарти я не цепляю. Я привожу в пример. Ведь его можно использовать, как шаблонизатор? Если у тебя есть личная неприязнь к смарти, я готов заменить на XSLT.

Добавлено через 3 минуты и 43 секунды
Fortop, 
ты хотел сказать - общий вью?


Это сообщение отредактировал(а) Feldmarschall - 22.7.2008, 21:56

Feldmarschall, процитирую Википедию



Ключевые слова - модификация одного из компонентов оказывает минимальное воздействие на другие компоненты
Модель MVC позволяет раздробить целое на несколько логически независимых частей.

Мы вообще все делим как можно мельче и приводим к иерархиям.

А так же решает вопрос bars80080   

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

Но оглядываясь на то что уже сделано, я бы вообще функции экспорта вынес отдельно.

Единственное что пока не решил, как это организовать.
Пока исходя из архитектуры - лучше отдельным контролером. Слишком часто повторяющаяся операция у меня.

использовать можно, но не нужно   

Fortop, то есть, главное в MVC - не общий индекс (о котором так много писал HackMan), а объектная модель (не в смысле model, а в смысле модель построения сайта с использованием ООП)? 
А роль общего индекса вполне может играть умный рерайт с препендом на пару, правильно?


Вот только вопрос, сколько ему это будет стоить.

Это сообщение отредактировал(а) Feldmarschall - 22.7.2008, 22:10

да

Я ни разу не утверждал, что общий индекс - главное в MVC. Это фраза, выдранная из контекста. Главную задачу MVC я процитировал с Вики


да   

Это сообщение отредактировал(а) HackMan - 22.7.2008, 22:16

Дело в том, что сама архитектура веб прямо таки способствует разделению логики.
Model - база данных
View - html, javascript etc...
Controller - PHP.

Я недавно пытался объяснить это обычным десктопщикам - но для них это что-то заоблачное.
они не понимают как могут кнопки и форма жить отдельно от всего остального приложения 

Fortop, в модели не обязательно только работа с СУБД

И для окончательной понятности ещё одна цитата с Вики


Это сообщение отредактировал(а) HackMan - 22.7.2008, 22:19

ему это будет стоить много отрицательных рублёв, ибо он на этом ещё заработает
не продажей, так работой

фигасе я холивар развёл

спасибо большое за обсуждение
Feldmarschall, ты так и не рассказал, что считаешь правильным

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

я пока примерно так думаю (иллюстрация HackMan)
объединять я ничего не хочу, именно поэтому клепаю независимые модули. скорее всего это будет разрозненные папки с файлами модуля. единственное, что все их конфиги будут цепляться за главный в корневике. в таком случае переложение на другую задачу будет довольно быстрое
точки входа тоже будут разные. скажем index.php для общего сайта (новости, инфо для клиентов, формы заказа и т.п.), система управления и редакции (admin.php) для наполнения контентом и общим управлением, ну и другие обособленные от остального блоки, типа forum, shop и т.п.
на всё общая БД с общими таблицами на авторизацию и доступ, но в остальном разные.

что не так сказал?

Мне модели у HackMan, не нравятся. Не отражают сущности. Т.е. и такие могут быть, но еще должны быть и более низкого уровня с которыми эти будут работать.
например общая модель User.

Согласен, модели не лучшие, но они тоже отображают принципы MVC, и для поставленной задачи сгодятся