WebScript.Ru
C:\   главная  ::   о сайте  ::  каталог скриптов  ::  гнездо  ::  форум  ::   авторам  :: Новостройки ::   ХОСТИНГ  ::

|| разделы::
|| поиск по сайту::

|| реклама::
|| новости почтой::
Рассылки Subscribe.Ru ::



Новости сайта WebScript.Ru
Популярные статьи

Hot 5 Stories

|| рекомендуем::




Долой процедурное программирование, даешь объектно -ориентированное!


Прислал: Dmitry Vereschaka [ 30.06.2003 @ 19:53 ]
Раздел:: [ Статьи по PHP ]


Программисты - народ ленивый. Поэтому, когда дело доходит до работы, они сначала ищут в сети какой-нибудь программный продукт, который в той или иной степени удовлетворяет их потребности в решении поставленной задачи. Если программист пишет что-то на PHP, то одной из первых систем, которые он найдёт, будет PHP Nuke. Поигравшись с ним некоторе время, программист понимает, что вещь, конечно, хорошая, но слишком уж "коряво" написанная, тяжело адаптируемая к задачам, отличных от web-портала, да и перевод на русский язык сделан человеком, имевшем не более трёх очков по великому могучему.

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

Общая схема этого похода, называемого "модульным", такова: Существует некий главный скрипт, например index.php. Этот скрипт в неком параметре, например, $module, принимает имя модуля, который отдаёт браузеру какую-нибудь страницу. index.php выглядит примерно таким образом:

<?
include "config.php";
if (!$module || !file_exists("modules/$module.inc.php")) {
$module="default";
}
include "modules/$module.inc.php";
?>

Типичный "модуль" при таком построении сайта выглядит так:

<?
if (!eregi("index.php", $PHP_SELF)) { die ("Access denied"); }
$page_title="..."; // устанавливаем имя страницы
include "includes/header.php"; // подключаем дизайн
// некий php - код, который генерирует данную страницу
include "includes/footer.php"; // подключаем остатки дизайна
?>
Вроде бы всё хорошо, однако есть некоторые но:
  1. В кажом модуле нужно делать include заголовка - иначе не сможем изменить <title> и другие тэги в начале страницы.
  2. В кажом модуле необходимо делать
    if (!eregi("index.php", $PHP_SELF)) { die ("Access denied"); }
    - чтобы не вызвали напрямую, миновав различную инициализацию переменных, подключение к СУБД, include общих функций и т.д. в config.php. Хотя, на самом деле, такой запрет делается тремя строчками в .htaccess:
    <files *.php>
    deny from all
    </files>
    
  3. В каждом модуле надо делать include нижней части страницы - по той же причине, что и п.1
  4. При программировании модулей приходиться многократно вызывать одни и те же процедуры: генерацию меню, навигации, банеров, голосований и т.д. Даже если все эти процедуры будут с красивыми, легкозпоминаемыми именами, с небольшим количеством параметров, будут содержать всё HTML-форматирование внутри себя, то всё равно каждый раз при написании модуля надо будет последовательно написать вызовы всех этих процедур:
    <?
    PageNavigation(module params);
    PageLeftMenu(module params);
    // PHP-код, генерирующий контент
    PageRelatedLinks(module params);
    PageNewsLinks(module params);
    PageVotes(module params);
    PageBanner(module params);
    ?>
    
  5. Другие но, забытые как страшный сон
Таким образом, написание нового модуля начинается с копирования текста старого модуля с последующим исправлением блока, ответственного за контент.

Однако есть способ избавить себя от этого монотонного, длительного и никому не нужного процесса - для этого нужно вспомнить о существовании ООП (объектно-ориентированного программирования) и о том, что PHP очень неплохо это самое ООП поддерживает.

Для начала создадим класс - Web-страницу, в которой опишем все фунции, используемые при генерации наших страниц:

class WebPage
{
// если имя функции совпадает с именем класса, то она считается конструктором
// говоря по-русски, она выполняется при создании объекта
function WebPage($module)
{
$this->page_title="демо-модуль";
}
function PageHeader()
{
include "includes/header.inc.php";
// в этом файле вместо <?=$page_title;?> надо будет написать <?=$this->page_title;?>
}
function PageFooter()
{
include "includes/footer.inc.php";
}
function PageNavigation()
{
// Код для навигации
}
function PageLeftMenu()
{
// Код для меню в левой части страницы
}
function PageContent()
{
// Код, генерирующий контент
}
function  PageRelatedLinks()
{
// Код, генерирующий ссылки на связанные разделы
}
function  PageNewsLinks()
{
// Код, генерирующий блок новостей
}
function  PageVotes()
{
// Код, генерирующий блок голосований
}
function  PageBanner()
{
// Код, генерирующий баннер
}
function Run()
// ф-я Run последовательно вызывает все необходимые 
// методы класса WebPage для построения страницы
{
$this->PageNavigation();
$this->PageLeftMenu();
$this->PageContent();
$this->PageRelatedLinks();
$this->PageNewsLinks();
$this->PageVotes();
$this->PageBanner();
}
}
?>
Теперь, если нам надо сделать, например, страницу, которая отличается отстандартной только блоком контента, то мы можем определить новый класс, производный от WebPage:
class CoolPage extends WebPage
{
// переопределяем конструктор, чтобы изменить имя модуля
function CoolPage()
{
// вызываем конструктор родительского класса - вдруг он что-то полезное делает? ;)
parent::WebPage();
$this->page_title="Крутой модуль";
}
function PageContent()
{
// выводим контент
}
}
если нам на странице не нужны новости, то мы определяем другой класс:
class CoolPageWithoutNews extends CoolPage
{
// здесь мы не описываем фунцию CoolPageWithoutNews 
// в этом случае PHP автоматически вызовет конструктор родительского класса
// соответственно имя нашей страницы будет "крутой модуль"
function PageNewsLinks()
{
// тут пусто, чтобы ссылки на новости не выводились
}
}
и так далее.

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

Вот пример файла index.php, который может выступать в качестве "главного файла":

<?
include "config.php";
include "base_classes.php";
if ($module && file_exists($file="modules/$module.inc.php")) {
// проверяем, есть ли файл с "телом" класса
include $file;
}
if (!class_exists($module)) {
// проверяем, что класс существует
$module="WebPage";
}
$page=new $module; // создаём объект
$page->Run(); // запускаем генерацию страницы
}
?>
Примечание: не смотря на то, что весь приведённый выше код ни разу не запускался, вышеуказанная технология, с той разницей, что почти вся информация находится в БД, реально эксплуатируется, например, на моём сайте - dmitry.rsl.ru


 :::::  RomikChef пишет 30.06.2003 @ 20:11 
Очень смешной довод за ООП и против процелур.
Родной, ты с чем воевал - с процедурами или с инклюдами в индекс?
Если второе, то я тебя горячо поддерживаею.
Если второе, ты на арене цирка смотрелся бы гораздо лучше.
Все то же самое можно сделать процедурным программированием, или вообще без него.

Да и с классом ты очень сильно облажался.
части веб страницы как части класса - это очень сильно.
Чтобы добавить элемент на страницу, надо добавлять элемент в КЛАСС!
Даже не в объект, а в класс.
Учиться тебе еще и учиться.
 :::::  Xander пишет 30.06.2003 @ 20:41 
Не знаю, насколько мой пример адекватнее, но index.php в очень черновом варианте выглядит так:

<?
require("Forum.class.php");
$forum = new Forum();
?>
<html>
<head>
<link rel="stylesheet" href="style.css" type="text/css">
</head>
<body>
<a href="post.php">Новое сообщение</a>
<? if (!$msgid=$_GET['msgid']): ?>
<div class="tree">
<? echo($forum->GetBaseTopics()) ?>
</div>
<? else: ?>
<div class="message">
<? echo($forum->GetPost($msgid)) ?>
<a href="post.php?msgid=<?= $msgid ?>">ответить</a>
</div>
<? endif; ?>
</body>
</html>
 :::::  Ray Adams пишет 01.07.2003 @ 09:51 
Хочу конечно поздравить автора за хорошую попытку наезда на мою статью про модульбное програмирование. ООР это круто! НО НЕ НА PHP!!! На VC++ или Delphi запросто! Но PHP плохо подходит для этого дела! Почему? Да потому что не оптимизирован нормально. Примеры? Мне как то дали один сайт проверить, мои друзья хостеры. Сказали что почемуто сайт сильно торзозит и грузит сервер. Дали ФТП , ну я глянул и чуть не помер. Такого изврата на обьетками я еще не видел!!! Страница ничего не содержащая создавалась сервером 2-3 секунды. Как мне потом сказали, чувака , который написал сайт, так учили в институте! Растрелял бы таких преподов!
---
А по поводу статью хочу еще добавть. Я не вижу никакой
 :::::  Ray Adams пишет 01.07.2003 @ 09:55 
разницы между обьектным и простым подходом. Теже инклюды , все тоже. Хотелось бы спросить автора, а что нибудь очень большое (портальчик хотябы) был вами написан? Кроме того сайт что дан в конце. Там я ничего не нашел крутого и на этом сайте применены обьекты???
---
Да и прошу не считать за наезд, мне просто интересно понять мысли человека.
 :::::  advocat пишет 01.07.2003 @ 11:49 
Это круто, заходим значит на dmitry.rsl.ru (сайт указаный внизу статьи), и что мы видим:
insert into x_ui_log (referer_id,cookie_id,template_id,user_ip,proxy_ip,uid,access_time,ua_id) values(225,535,29,'unknown','192.168.0.24',24,now(),140): ERROR: invalid INET value 'unknown'

Вот когда исправишь свои ошибки, вот тогда и будешь учить других...
 :::::  Dmitry Vereschaka пишет 01.07.2003 @ 16:21 
2Ray Adams: Давай не будем рассуждать о том, что OOP не подходит для PHP - это полная чушь. Чтобы в этом убедится, посмотри на анонс PHP5 - 90% улучшений связанно именно с OOP. По поводу твоего примера - не факт, что тот сайт тормозит именно из-за объектов. Кроме того, если кто-либо не умеет программировать, то он и без OOP сможет многократно замедлить скорость выполнения скрипта. Так что твой пример не показателен. Что касается разницы - её начинаешь чувствовать, когда у тебя на сайте больше 5 разновидностей страниц, при этом они почти все, за некоторыми досадными исключениями, на борьбу с которыми тратится 90% времени, одинаковые. Кстати, список моих работ находится в разделе резюме моего сайта.
2RomikChef: Не стоит воспринимать пример как руководство к действию. Всё вышеописанное - всего лишь повод для раздумий. Тем не менее страницы сайта очень хорошо ложатся в идеологию OOP - в частности, очень удобно реализовывать наследование. Если у тебя есть некий базовый шаблон (читай, при грамотном базовом классе web-страницы), то описание новых новых шаблонов происходит путём исправления двух-трёх методов. А воевал я на самом деле за ссылку на свой сайт. И знаешь, я её получил :)
2advocat: Спасибо за найденный баг. А не ошибается только тот, кто ничего не делает.
 :::::  [BlackRaven] пишет 02.07.2003 @ 09:07 
э... чейто вы с классом перегнули... да и вообще - имхо подход как и в ПхпНьюк - комбайнерсикй (программист, он же дезигнер)...
ОТВЕТ :: НЕ_КАТИТ

уходить надо от этого. да и темболее раз автор статьи - создовал CMS, то назревает вопрос - что же за CMS он создовал?.

имхо шаблоны - рулез.

в ПхпНьюке подход правельный, а вот его реализация хромает малость.
 :::::  Dmitry Vereschaka пишет 02.07.2003 @ 10:04 
Перефразируя один широко известный закон Мерфи, можно сказать: Первый миф науки о шаблонах состоит в том, что она существует.
Беда в том, что в общем случае контент нельзя отделить от представления. И если на страничке находится что-то более сложное, чем "hello, world", то дизайнер должен стать программистом на языке используемоего Template Engine. В итоге в систему добавляется новое звено со своим коэффициентом надёжности, гораздо меньшем чем 1, - ведь если человек профессиональный дизайнер, то скорее всего он очень далёк от программирования, - и вероятность того, что всё будет работать правильно уменьшается еще на некоторую величину, т.к. ошибки программера налагаются на ошибки дизайна и еще на ошибки шаблона. Да и локализовать причину ошибки будет сложнее - у программера будет больше поводов наехать на дизайнера, и наоборот.
В общем, если будет время, я напишу отдельную статью на эту тему ;)
 :::::  [BlackRaven] пишет 03.07.2003 @ 11:12 
из твоих слов можно сделать вывод ::
стать дезигнером проще чем программистом.

тока вот что в действительности проще
- выучить несколько конструкций, и интуитивно понятных тегов
или
- научиться рисовать
???

а по поводу надежности можно долго спорить, да и скорость тоже не подведет если грамотно использовать кеширование.
 :::::  Dmitry Vereschaka пишет 03.07.2003 @ 11:45 
Совершенно некорректный вывод. Просто у меня есть опыт, который говорит о том, что программисты и дизайнеры как бы существуют в параллельных мирах - простейшая задача с точки зрения программирования ставит дизайнера в тупик, и наоборот. Может быть я был знаком с неправильными дизайнерами.
Ну а в целом ты прав - спорить можно долго ;)
 :::::  Макс пишет 06.07.2003 @ 16:30 
Я, конечно, обеими руками за использование ООП при написании скриптов, но за РАЗУМНОЕ использование.
В данном же случае ты взял один метод модульного программирования (ИМХО не самый лучший) и показал пример, как это можно сделать в ООП-стиле (ИМХО пример тоже далеко не лучший) .

> Вроде бы всё хорошо, однако есть некоторые но:
многие НО, которые ты описал не являются проблемой либо решаются красиво и без ООП.

> в общем случае контент нельзя отделить от представления
C XML/XSLT знаком ? Чем не отделение контента от представления ?

> то дизайнер должен стать программистом на языке используемоего Template Engine
во-перых это не обязаность дизайнера - верстать шаблоны.
Во-вторых никто не требует от тебя использовать Smarty или другие шаблонизаторы с развитым языком. Мне например всегда хвтало мток и блоков как в phplib::template либо просто меток как в шаблонизаторе, описанном в одной из статей на єтом сайте.


По поводу самой темы
ИМХО преимущества ООП проявляются в проэктах на порядок сложнее приведенного. К сожалению такие примеры сложно описать в коротких статьях понятными новичку терминами, поэтому к ним многие программеры приходят сами.
 :::::  Dmitry Vereschaka пишет 07.07.2003 @ 10:16 
XML/XSLT - это всё игрушки. Пока что очень слабая математическая база. Например, если у меня есть некий контент, назовём его A, и есть некоторое окончательное представление, например, B, то ни один человек и ни одна софтина не сможет мне предъявить такое xslt f, чтобы B=f(A). Или уже есть?
По поводу замечаний: естественно, мой пример не идеален. Просто я попытался методом сравнительного позиционирования /(c) Виктор Пелевин/ со статьёй господина Ray Adams'а показать, что даже минимальное привнесение в проект ООП может помочь перестать думать о некоторых мелочах и сделать код намного компактнее, красивее и понятнее. Естественно, как ты верно подметил, что в такой короткой статье и в таком маленьком примере сложно описать преимущества ООП.. Но тем не менее я считаю, что публикация удалась - она, так сказать, получила "широкий общественный резонанс" и, будучи прочитанная вместе с комментариями, поможет начинающему web-программисту сделать определённые выводы.
 :::::   пишет 07.07.2003 @ 16:01 
> XML/XSLT - это всё игрушки.
:)))))
(больше сказать ничего не могу)
 :::::  Макс пишет 07.07.2003 @ 16:03 
предыдущее сообщение мое
 :::::  Oleg пишет 09.07.2003 @ 23:09 
Вот Вы говорите ООП это СУПЕР СУПЕР и СУПЕР просто без него ну никак. Template - это непонятное чтото и вообще ненужное. Девиз "Все на ООП !". Зашибись. Но я не вижу смысла использовать ООП на столь простых сайтах где большей частью только клиент получает информацию. Я ЗА Template.

Представте себе сайт написан с использованием Templatов и админка к нему тож Templatы использует и без всякого там ООП весит в общей сложности до 120-150 Kb.

А др. программер писал этот же сайт(и админку) с теми же возможностями и с применением Template + ООП
весит 890 Кб. Причем "наражал" кучу Классов. Все СУПЕР только сам в них разбирался очень при очень долго, при малейшем изменении.

И это человек с опытом программирования в ООП около 7-8 лет "Матерый Волк".

И Вы хотите сказать что тут ООП лучше ? для простого сайтика ?






 :::::  [BlackRaven] пишет 10.07.2003 @ 16:23 
ради интереса посмотрел сколько конструкция используется в моей библиотеке (громко сказано, так файлик с функциями) шаблонов. оказалось всего четыре штуки.

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

з.ы.
а шаблоны рулят, главное чтобы верстальщик был хороший...
 :::::  tommy пишет 10.07.2003 @ 16:54 
Ray Adams написал хорошую статью по модулям
а это просто бред какойто
особенно умиляет заявление что при модульном программыровании надо каждый раз
в текст модуля включать header/footer и прочее

 :::::  Quest пишет 16.07.2003 @ 02:55 
ООП толком не знаю, ну думаю что пора за него браться в серьез... И вот почему... при написании сайта .. все начиналось конечно с простого include() и при дельнейшем добавлении сервисов (поиск, комментирование) столкнулся с проблемой интеграции в сущесвтующий движок... хотя используемые в работе алгоритмы - просто примитивны ("все гениальное -просто...") потребовалось немало времени чтоб заставить все это работать... Думаю, что при ОПП было бы все намного легче.. Но использовать столь громоздкие конструкции при написании простого и незамысловатого сайта - полный бред... Все упирается в соотношение "ЦЕЛЬ-СРЕДСТВО"
 :::::  tommy пишет 16.07.2003 @ 17:53 
ну нет !
фанаты ООП даже очень простые задачи и особенно то что можно решить более удобно, быстро с минимальным количеством отнимаемых у работающей системы ресурсов
будут решать описанными выше извращенными способами
(Для них - ООП - ВО ЧТОБЫ ТО НИ СТАЛО !!! )

ООП - конечно рулит !
но только
1 оно нам не надо
2 в данном случае - модульное программирование избавит от геморроя с ООП
(и увеличит скорость работы программы/спасет сервер хостера от медленного но верного умирания)

 :::::  Макс пишет 17.07.2003 @ 17:06 
tommy
только не надо говорить что ООП является причиной "умирания" сервера. ООП конечно замедляет работу скриптов но не настолько. Все зависит от криворукости программера
 :::::  talker пишет 24.07.2003 @ 08:26 
1.А что есть шаблоны, как не КЛАССЫ в терминологии ООП, только без методов?
2.Что есть модуль, как не элемент инкапсуляции(с некоторыми вариациями)?
3.На каждую технологию программирования имеются определенные накладные расходы. В случае модульного ( процедурного, функционального) программирования ДЛЯ ОДНОГО экземпляра они, как правило, меньше, чем для ООП. Для больших и сложных проектов ситуация меняется в пользу ООП.А расходы на сопровождение и изменения вообще несопоставимы.
4.Web технология по своей природе тяготеет к функциональному программированию,т.к. сервер в общем случае не хранит состояние(есть, конечно, сессии). Таким образом, каждый запрос
является по сути вызовом ФУНКЦИИ (процедуры) с передачей ей параметров. В ООП нужно бы вызвать метод объекта. Беда в том, что этого объекта на сервере уже нет, и приходится на основе переданных параметров его восстанавливать.
5.По вопросу скорости - см.накладные расходы. Кстати, на днях тестировал XML/XSLT - на 10000 записей загибается. Эту технологию хорошо применять на сотне-другой записей, но при таких объемах я и скриптом обойдусь
6.В сложных системах иерархия объектов ПРОЩЕ иерархии вызовов процедур, и главное - "модульнее".)))
7. Аргумент хорош - "оно нам не надо". Исчерпывающе.

 :::::  MOPO3 пишет 24.07.2003 @ 09:49 
2 tommy :
>ну нет !
>фанаты ООП даже очень простые задачи и особенно то что можно решить более удобно, быстро >с минимальным количеством отнимаемых у работающей системы ресурсов
>будут решать описанными выше извращенными способами
>(Для них - ООП - ВО ЧТОБЫ ТО НИ СТАЛО !!! )

Stranno , no pochemu to poslednee vremia vse stremiatsia k OOP. S .NET znakom ??? Jazik C# v chastnosti ? Tam mezhdu prochim dazhe "Hello World!!!" i to class !!! Ili Melkosoft ne prav v svojom podhode k programmirovaniju ?

 :::::  Juggler пишет 24.07.2003 @ 14:57 
ООП не облегчит Вам процесс написания кода.
Вы не потратите меньше времени на написание кода.
ООП внесет упорядоченую(стройную) логику в программу.
Только для того чтобы это произошло надо правильно спроектровать классы.
В свою очередь надо хорошо представлять предметную область.
Я могу предложил продолжеие статьи, а называлось оно так
"Сравнение двух методик программирования приобновлении( модернизации ) сайта".
Проще сказать, берем два простых примера 1й ПП 2й ООП, а потом начинаем навешивать
различные дополнения. После определенного этапа(кол-ва кода) время на внесение
изменений в программу написаную с помощью ООП будет сокращаться, а в программу написаную
с помощью ПП будет увеличиваться.
Это можно рассматривать так- болт,гайка,шестеренка,корпус можно сделать и собрать без чертежа но когда таких деталей 20 и более(двигатель,мат.плата) то не имея чертежа
вы будете очень долго собирать изделие. Так вот классы это и есть чертеж.





 :::::  Juggler пишет 24.07.2003 @ 15:01 
ООП не облегчит Вам процесс написания кода.
Вы не потратите меньше времени на написание кода.
ООП внесет упорядоченную(стройную) логику в программу.
Только для того чтобы это произошло надо правильно спроектировать классы.
В свою очередь надо хорошо представлять предметную область.
Я могу предложить продолжение статьи, а называлась оно так
"Сравнение двух методик программирования при обновлении( модернизации ) сайта".
Проще сказать, берем два простых примера 1й ПП 2й ООП, а потом начинаем навешивать
различные дополнения. После определенного этапа(кол-ва кода) время на внесение
изменений в программу написанную с помощью ООП будет сокращаться, а в программу написанную с помощью ПП будет увеличиваться.
Это можно рассматривать так- болт, гайка, шестеренка, корпус можно сделать и собрать без чертежа, но когда таких деталей 20 и более(двигатель, мат.плата) то не имея чертежа
вы будете очень долго собирать изделие. Так вот классы это и есть чертеж.






 :::::  Croaker пишет 25.07.2003 @ 12:29 
2Dmitry Vereschaka
Не смотря на все вышесказаное - довольно простой и понятный пример использование ООП для тех, кто с ним не знаком.

2Ray Adams
На счет твоей статьи я уже высказывался там и до сих пор остаюсь при своем мнении.
>Хотелось бы спросить автора, а что нибудь очень большое (портальчик хотябы) был вами
>написан?
1. Написаный "Портальчик" не характеризует программиста, т.к. можно написать как грамотный и хорошо написаный домашний сайтик, так и идиотский, кривой и никому не нужный "портальчик".
2. В случае большого проекта, как уже было выше сказано, ООП со временем систематизирует хранение и исполнение кода, а ПП приводит к каше в файлах.

2ALL кто высказывался за шаблонны и\или XSLT\XML
1. Основная "фича" в ПХП (если забыли) состоит в том, что он может ВСТРАИВАТЬСЯ в html. С переходом на шаблоны эта фича само собой пропадает.
2. Для небольших сайтов использование шаблонов не упращает разработку сайта, а наоборот замедляет (как скорость выполнения, так и скорость разработки), в скриптах появляются килобайты ненужного когда, а польза от использования шаблонов (как и XML\XSLT) весьма и весьма сомнительная. Пример одного и тогда же действия и использованием шаблонизатора (FastTemplate):

1. На шаблонах (довольно урезаный к тому же):

require ('class.FastTemplate.php');
$tpl = new FastTemplate('./tpls/');
$tpl->define(array ("file" => 'file.tpl'));
$htmlTitle = 'Заголовок страницы';
$tpl->assign("{htmlTitle}", $htmlTitle);
$tpl->parse(resHTML, "file");
$tpl->FastPrint();

html:
...<title>{htmltitle}</title>

2. И код стандартными средствами ПХП:
$htmlTitle = 'Заголовок страницы';
require ('file.tpl');

html:
...<title><?=$htmlTitle?></title>


Почувствуйте разницу.

Использование шаблонов штука конечно модная, но как правило она используется неоправдано.
Использовать шаблоны надо только если проект 1) большой 2) над ним ведется работа командой разработчиков, т.е. нужно действительно раздеять код, потому что это УСКОРЯЕТ и УПРОЩАЕТ разработку.

Использование ООП оправдано везде, т.к. 1) класс, написаный один раз можно использовать в других проектах, что, опять же, ускоряет процесс разработки. Хотя в PHP (в принципе) можно реализовать так же просто и модульным программированием 2) ООП структурирует код, что так же можно добиться и модульным программированием, но, на мой взгляд, несколько сложнее.



 :::::  tommy пишет 26.07.2003 @ 15:59 
>Stranno , no pochemu to poslednee vremia vse stremiatsia k OOP.
ничего странного
но мы говорим о php (под apache и тп)
> S .NET znakom ??? Jazik C# v chastnosti ?
еще нет. но это достойно изучения это точно
>Tam mezhdu prochim dazhe "Hello World!!!" i to class !!! Ili Melkosoft ne prav v svojom podhode k programmirovaniju ?
в подходах к программированию он всегда не прав.
но ,возможно , .NET и C# явилось исключением

ну неоправданно использование OOP в программированиие на php
и в частности для написания порталов

не писал я что против OOP ! я говорю : тут это неоправданно , неудобно , медленней работает чем при чисто модульном подходе.
зачем мне возиться с классамии, левыми функциями и прочей хренью если я просто пишу модули и все !
эта статья : припарка OOP к томуже модульному программированию
(все равно те же include есть (на которые автор так злобно и издевательски нападает!!! ) ... нахрена тогда сюда это "OOP для реализации портала в видении автора статьи" ?) ...

 :::::  Макс пишет 27.07.2003 @ 12:32 
2 talker
> 5.По вопросу скорости - см.накладные расходы.
> Кстати, на днях тестировал XML/XSLT - на 10000 записей загибается

1. Такие заявления желательно подтверждать исходниками (а то, кто его знает как ты все это тестировал)
2. Какой смысл выводить 10000 записей ? Обычно постраничная разбивка применяется.
3. Если ты использовал sablotron для парсинга XML то по мнению некоторых людей (которые не первый день занимаются XML) ему лучше не давать парсить файлы более 100 КБ



2 Croaker
1. Во-первых эта "основная фича" есть во многих других языках программирования - jsp,asp, (не совсем языки но мысль мою ты понял.
2. По поводу XML - я уже на форуме писал. Преимущество связки php+xml/xslt в том, что если нужно сделать небольшие изменения в дизайне, нужно редактировать только xslt-шаблоны (при условии что ты правильно спланировал XML-струкутру) и не надо править пхп-код. Насколько я помню это все неплохо описано на detail.phpclub.net


 :::::  Juggler пишет 28.07.2003 @ 17:06 
По поводу php+xml/xslt.

На сколько я знаю. Все файлы html,xml,xslt,dtd текстовые.
Соответственно, что Вам мешает их менять(кодом - не руками) в обход парсера.
Парсеру подставляете буффер или временный файл и все ОК.
Работайте как хотите.

По подову include.
Если у вас в "С" встроены функции fopen и fclose.
То почему я не должен их использовать или их использование должно считаться смертным грехом
если я пишу классы.

По поводу С#
Фраза "Привет Мир" в классах это тоже самое что пример приведенный выше.
Мы показываем вам как можно правильно создать простую программу на этом языке с
использованием классов. У Страуструпа на С++ тоже есть пример с "Привет МИР" на классах
хотя с такимже успехом можно было этого не делать. А можно было написать cout<<"Привет МИР".

По поводу FastTemplate
2. И код стандартными средствами ПХП:

$htmlTitle = 'Заголовок страницы';
require ('file.tpl');

html:
...<title><?=$htmlTitle?></title>

А попробуйте сюда добавить еще что то, ну скажем файл с заголовокм, а в этом заголовке
две переменные и видно их только отсюда. Я посмотрю где код короче получиться с
Fast Template или у Вас.
Байка:
1. Вы возводите дом собственными силами и применяете китайский инструмент.
2. Вы строите дом, но применяете самый дишевый немецкий инструмент и мал.механ.
(Кто раньше построит?) Только прошу не вдаваться в полемики по поводу трудолюбия!

По поводу ООП
Все авторы по ООП пишут что начальные затраты времени на разработку классов выше чем
затраты по дальнейшему их сопровождению.
Если сравнивать то получиться следующие:
1. Вы строите дом по частям сначала одна часть фундамента потом одна комната потом другая и
т.д. (в народе завется сарайчиками).
2. Вы строите дом по чертежу - сначала фундамент потом стены.
(кто будет жить в новом доме раньше?)
Последняя байка:
Когда выбираешь машину смотриш сколько она стоит и какая цена на запчастия.
Можешь выбрать дешевуюв цене, но дорогую в обслуживании.



По поводу FastTemplate и php+xml/xslt
Что Вам мешает собирать файлы xml/xslt/dtd по частям c помощью FastTemplate.


 :::::  Photus пишет 28.07.2003 @ 17:22 
Здравствуйте, веб-программеры.
К вам обращается чистый(Delphi, CBuilder) программист, решивший как-то написать сайт на ПХП( http://psd.h10.ru ).
Хочу вклиниться в дискуссию об ООП. Даже в нормальном программинге умеют использовать преимущества ООП 1 из 100, а может и меньше. Все другие иногда очень жалеют что попытались тот или иной проект написать используя ООП(т.е. некоторые его возможности, ведь на самом деле когда пишешь на Дельфи по любому ООп используешь).
Но в веб-программинге ООП использовать разумно я даже не представляю как? Может кто-нить направит меня на хорошую статейку.
 :::::  Макс пишет 29.07.2003 @ 02:24 
2 Juggler
ИМХО для формирования XML - есть более удобный способ - domxml

Photus
если тебя интересует ООП в ПХП то можешь глянуть http://pear.php.net как пример
для perl - есть книга по OOP в PERL (видел только на английском)
про java-сервлеты я молчу (там и так все на классах)
 :::::  Juggler пишет 29.07.2003 @ 15:00 
Ответ Максу
По поводу domxml.
Тут зашла речь что применение ПХП теряет смысл если использовать XML.
Я просто сказал что если файл текстовый то его можно резать и соеденять с помощью
ПХП без всяких парсеров, то есть ручками(гвоздями,клеем и т.д.).
Одним словом ПХП это универсальное средство работы над текстовой информацией.
Не имеет значение для ВЕБ или нет. Я с такимже успехом могу работать с Ораклом
а результаты выдавть(печатные формы) с помощью ПХП в файл,принтер,терминал(текстовый).
Да и простые БД можно писать.

По поводу ООП
Пример приведенный выше простой, и не демонстрирует основных преимуществ ООП.
Но как пример для начинающих не плох.

Я хотел бы чтобы автор написал продолжение и показал использование
инкапсуляции,полиморфизма,простого и множественного наследования,виртуальных и
абстактных методов.
Пример с использованием иерархии наследования классов показал бы приемущество ООП в плане структуризации кода.
К томуже в ПХП есть множество функций для работы с классами и объектами.




 :::::  Макс пишет 29.07.2003 @ 16:54 
2 Juggler
1. в пхп 4 нет полиморфизма и множественного наследования (хотя полиморфизм может искуственно организовать)
2. обычно в ПХП 4 не используется сложная иерархия классов (хотя это все я пишу исходя из своего опыта).
Наиболее близкое к ООП-стилю из того что я видел - это phpMVC (где-то на sourceforge было) и в архивах конференции pear.dev пару месяцев назад кто-то предлагал свою версию реализации MVC-паттерна
(я имел ввиду написание скриптов в ООП-стиле а не простое использование ООП)

3.
> Тут зашла речь что применение ПХП теряет смысл если использовать XML.
Нет, вот примерная схема :
СУБД -> XML + XSLT = > HTML или WML или PDF или RSS или ЧТО-ТО ЕЩЕ
пхп используется для доступа к СУБД и перевода результатов запроса в XML + пхп решает какой именно XSLT шаблон наложить чтобы получить HTML или WML ....
Конечно же вместо пхп можно использовать и перл и яву и асп

4.
> Я просто сказал что если файл текстовый то его можно резать и соеденять с помощью
> ПХП без всяких парсеров, то есть ручками(гвоздями,клеем и т.д.).

простые операции может быть и можно провести, но когда понадобиться что-то посложнее - без doxml (и его XPATH-функций) будет сложно.
 :::::  Juggler пишет 30.07.2003 @ 10:10 
Ответ Мксу

Пункт 1.
Полностью согласен.

Пунк 3.
Интересно как ты получаешь данные из СУБД прямо в XML?
СУБД -> (ПХП+парсер)->XML + XSLT = > HTML

Пункт 4.
Без парсеров работать с XML неудобно. Но не кто не говорил что работать без него нельзя.

Я здесь смотрю что тема исчерпана.
Впрочем здесь столько наговорили что статей 10 можно написать.
Всем пока!


 :::::  Neo (Meowth Twey) пишет 01.08.2003 @ 02:29 
Вот пример грамотных американских програмеров:

Возьмём, например, очень популярный в сети форум InisionBoard
1. Вообще он написан на PHP, хотя когда увидел в первый раз, то меня это смутило. Такая мощная вещь на PHP?? Да она же тормазить неимоверно должна. Я бы на их месте делал на Perl-е.
2. Закачиваем архив, открываем и копаемся. Одни классы и ООР.
3. Даже при всём этом форум очень быстро работает.
Вывод: ООР - это будующее. На это надо переходить уже сейчас.

P.S. А то что у некоторых это дело тормазит - это не показатель. Возможно ошибка в другом месте!
 :::::  Nekto пишет 06.08.2003 @ 16:40 
>Вообще он написан на PHP, хотя когда увидел в первый раз, то меня это смутило. Такая мощная вещь на PHP?? Да она же тормазить неимоверно должна. Я бы на их месте делал на Perl-е.


Ха-ха-ха.
Единственный способ ускорить программный продукт написанный не криворукими программерами - это писать его на компилируемом языке, перейти с базы MySQL на базу уровня Oracle. Ну и сервер побыстрее найти.

А вот что быстрее php или Perl... Хе. perl - мощнее. А вот скорость при нормальном программинге - одинаковая приблизительно.

С уважением, Сергей Тарасенко
 :::::  Макс пишет 12.08.2003 @ 14:30 
2 Nekto

> Единственный способ ускорить программный продукт написанный не криворукими программерами
> - это писать его на компилируемом языке, перейти с базы MySQL на базу уровня Oracle.

генерация статики уже не в моде ? :)
 :::::  Max пишет 16.09.2003 @ 16:12 
Мда....

Перл умирает. Даже оставив в стороне его смерть из-за отсутствия финансирования, будучи слабее C и корявей PHP он не имеет никаких перспектив и по сути единственное что его держит - cpan.

PHP - процедурный язык. А ООП - это надстройка над процедурами. И любое ООП в PHP грузит систему больше чем процедуры. И кстати не только в PHP.

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

К чему это все - а к тому, что у любой простой задачи всегда есть простое решение. Не надо выпендриваться и идти за модой.
 :::::  olymp пишет 01.10.2003 @ 17:05 
Буйно диспутировали - спасибо.
Конечно, ООП полезно, если предполагается расширение функциональности. Может быть даже необходимо - иначе рост потребует затрат с усоряющейся жадностью. Очень было полезно почитать противоположные точки зрения, и прийти к выводу ещё раз о том, что новая версия PHP5 задумана правильно - final и abstract позовлят работать с классами более гибко, интерфейсы вместо множественности наследования и полиморфизма тоже будут полезны.
 :::::  Design & Programming from ADC пишет 01.10.2003 @ 19:58 
ХАХАХА!

 :::::  Александр пишет 14.10.2003 @ 15:57 
Кому Perl, Кому PHP, кому еще что нибудь - какая разница на чем писать, главное чтобы код не был кривой, а то встречается такое: SELECT * FROM DATABASE, к 10 Гиговой MsSql базе.
 :::::  talker пишет 14.10.2003 @ 17:06 
Там выше был вопрос Макса по поводу быстродействия XML.
Не было парсинга! Берем простой XML файл(я брал файл импорта справочников из 1с ) и открываем его в IE5.5 При 10 тыс записей время открытия около 4 мин.
Прошу не кидать заметки по разбиению результата на страницы - операция была чисто тестовая.
Вывод: парсинг XML - весьма тяжелая штука... Кто видел ВС - бухгалтерию, которая вся построена на XML, тот поймет.
 :::::  Andr пишет 21.10.2003 @ 13:29 
Народ, помогите, плиз!
Есть html-сайт... он переезжает на хост с php но БЕЗ mysql.
Он с фреймом-менюшкой и страницами.
Подскажите, плиз, как бы закрыть возможность открытия файла как-либо, кроме как из фрейма-менюшки?
 :::::  Pr0Head пишет 04.11.2003 @ 19:14 
2 Andr: Тут РНР ни при чем.
Тебе нужен ява-скрипт, который бы проверял есть ли у текущей страницы родительское окно, если нет - редиректит на основную страницу.
 :::::  ask пишет 24.12.2003 @ 20:21 
даешь html-темплейты
например,
http://pear.php.net/package/HTML_Template_IT
 :::::  Алексей Чернигов пишет 21.08.2004 @ 19:25 
Автор тупорылый идиот. Таких бить надо. Ни грамма не может код нормально написать.
 :::::  Алексей Чернигов пишет 21.08.2004 @ 19:27 
А твой код содержит обычные include и тьму пустых функций. Очень позновательная статья, учит становиться ламмерами
 :::::  Eski пишет 19.09.2004 @ 11:31 
Хммм... Собственно, единственный плюс ООП в РНР(да и не только в нём...) это лёгкий рефакторинг кода. А так... Больше не за что его любить. Процедурный подход даёт преимущество в скорости, при том такое, что на тяжёлых проектах зачастую лучше забить на лёгкость переноса кода и писать процедурами.

2Александр
Смешно:))) А что сделает такой запрос, как ты думаешь, папа?=))))
10 гиговая мускула тоже весело%))))

Дальше...
хмл действительно хорош, правда, шаблоны писать на нём немного муторно, но результат того стоит, особенно если надо разделять один движок между несколькими его юзверями, то можно разрешить им _полностью_ собственный дизайн, не трогая движок. Да и не грузит он серевер, если парсить прямыми(или пропатчеными до прямых) руками.

Вроде всё,что хотелъ сказать%)))
 :::::  standov пишет 06.12.2004 @ 16:08 
2talker
Не хочу расстраивать, но XML выводится в IE c помощью стандартной XSLT-таблицы, которая. надо сказать весь кривая - сам смотрел.
А скорость парсинга XML - PHP5+DOM+Iteration + мой процессор Gear -> 1000узлов - 0.4сек, 10000узлов - 4сек на Cel1.3+512M(XP)
 :::::  Емельянов Данил пишет 26.04.2007 @ 21:34 
Я не могу понять, зачем использовать ООП в данном примере? Я- фанат ООП. Если использовать ООП в PHP, то PHP надо брать версии 5, не ниже. Только там реализована объектная технология. И все же ООП в PHP используется в не для борьбы с include, ересь какая-то.
 :::::  Gray пишет 23.05.2008 @ 21:34 
Даешь PHP6!
 :::::   пишет 31.10.2008 @ 21:48 
я конечно только начинающий прогммист, но мне кажется, что средствами языкы можно, как бы так правильней выразиться, самому написать конструкцию похожую на класс, которая будет работать примерно по такому же принципу. те же идентификаторы, инклуды, ф-ии, условия. у меня небольшой сайт и я зделал так:
в директории сайта лежит файл, который при запросе с помощью условий инклудирует уже нужный файл, состоящий из таких же инклудов, начинающих обрабатывать код.
да, их сто, но если открыть все сто сразу, вообще не проблема добавить новый инклуд в них. в файле состоящем из одних инклудов несложно разобраться почти неглядя, и выглядит поприятнее, чем класс.

Имя:
Email:
URL

Введите сумму двух чисел девять и одинн (девять+одинн=?)
Запомнить мою информацию

* Html запрещен* Ваш E-mail опубликован не будет.

Copyright © 2000-2001 WebScript.Ru nas@webscript.ru
Design © 2001 by Parallax Design Studio (aka Spectator.ru)
Все торговые марки и авторские права на эту страницу принадлежат их соответствующим владельцам.
Сгенерировано за: 0.0477231