LINUX.ORG.RU

Осваиваю ООП. Помогите с шаблонизацией.

 


1

3

Говорят, мешать HTML и PHP это плохо, но без этого очень сложно, — во многих CMS нет-нет да впихнут какой-нибудь span или div в постраничную навигацию. А иначе как? Создавать отдельный файл themes/default/pagelinks.php ради 10 байт кода, ради одного тэга? Ради того, чтобы было Ъ и не мешать код? Не смешите.

В моём случае, не вижу смысла вообще создавать темы оформления ради _каждого_ отдельного элемента сайта. Или надо? Статья, форма отправки комментария, комментарий (и предположительно их много): что ж теперь, на каждый элемент будет обращение к ФС за шаблоном? Скорости это не прибавит, знаете ли.

Учитывая, что делать темы оформления не планируется (код пишется под один дизайн), я не нашёл другого способа, кроме как «вкомпилить» шаблоны в PHP, но чтобы, так сказать, «не мешать с HTML», логически постарался их отделить в HEREDOC. Это нормально?

Теперь я осваиваю ООП, т.к. сказали, что мой код говно. Пытаюсь исправиться. В ООП всё есть «объект», каждый элемент сайта становится объектом. Ну ок.

Задача простая — нарисовать страничку, применив кучу объектов.

new Core(); // запускаем приложение

class Core {
  public function __construct() {
    $comment = new Comment();
    $comment_form = $comment->HTMLForm(); // рисуем форму для отправки

    $page = new Page();
    $page_html = $page->HTML(); // берём шаблон страницы по-умолчанию

    $template = new Template($page_html); // создаём шаблон из страницы
    $template->set('title', 'Comments');
    $template->set('content', $comment_form); // добавляем форму на страницу
    echo $template->show();
  }
}

class Page {
  public function HTML() {
    return <<<HEREDOC
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>$title</title>
</head>
<body>
$content
</body>
</html>
HEREDOC;
  }
}

class Comment {
  public function HTMLForm($options = array('action' => '/')) {
    extract($options);
    return <<<HEREDOC
<form action="$action" method="POST">
<textarea class="edits" wrap="soft" rows="5" name="message"></textarea><br>
<input class="edits" type="submit" value="add comment">
</form>
HEREDOC;
  }
}

class Template {
  public $theme = '';
  public $array = array();
  public function __construct($theme, $array = array()) {
    $this->theme = $theme;
    $this->array = $array;
  }
  public function __destruct() {
  }
  public function set($key, $value) {
    $this->array[$key] = $value;
  }
  public function get($key) {
    return $this->array[$key];
  }
  public function show() {
    extract($this->array);
    return $this->theme;
  }
}

Ведь как-то так и должно выглядить ООП? Очень прошу тыкнуть носом, где неправильно.

Идея в том, чтобы писать HTML-шаблон прямо внутри каждого элемента, каждого объекта. Чтобы исключить создание файлов-шаблонов и обращение к ним в ФС, а так же не плодить кучу мелких файлов размером десятки байт. Есть идеи лучше?

class Page {
  public function HTML() {
    return <<<HEREDOC
HEREDOC;
  }
}

class Article {
  public function HTMLArticle() {
    return <<<HEREDOC
HEREDOC;
  }
}

class Comment {
  public function HTMLForm() {
    return <<<HEREDOC
HEREDOC;
  }
  public function HTMLComment() {
    return <<<HEREDOC
HEREDOC;
  }
}

Как-то так. Самый главный вопрос — как эти шаблоны лучше распарсить? Делать return eval($this->theme); в классе new Template()->show(); кажется не лучшей идеей. В случае с файлами, конечно, делалось бы ob_start(); include $this->theme; return ob_get_clean();, но пугает множественное обращение к ФС и мелким файлам.

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

Буду рад, если поделитесь полезными ссылками по теме ООП в PHP.

★★★★★

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

Теперь я осваиваю ООП, т.к. сказали, что мой код говно. Пытаюсь исправиться. В ООП всё есть «объект», каждый элемент сайта становится объектом. Ну ок.
Задача простая — нарисовать страничку, применив кучу объектов.

You are doing it wrong.

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

Kilte ★★★★★ ()
Ответ на: комментарий от Kilte

нахрена тебе класс, когда можно было бы обойтись и без него.

это от собственного скудоумия, вы правы. обезъянка видит — обезъянка делает. вот и в моём понимании классы собой представляли бесконечный поток вызываемых функций, а полезного кода выполняют как кот наплакал. я их так видел.

а решить проблему с их помощью.

окей. уже решил. на самом деле решений имеется несколько, например, делать class Page extends Template, и тогда Page() начнёт работать как Template(), а значит переменные можно задавать и в Page().

но я просто дописал Template(), добавив ещё одну функцию специально для вывода HTML кода.

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

всем спасибо.

Spoofing ★★★★★ ()
Ответ на: комментарий от Spoofing

Выкинь всю эту наркоманию и возьми нормальный шаблонизатор. Вот, например: https://github.com/thephpleague/plates Не бойся, изучать новый язык, как в случае с Twig или Smarty не нужно, там нативные шаблоны.

Почитай про MVC в конце-концов. Ты словно из нулевых явился.

Kilte ★★★★★ ()

поэтому плодить сторонние файлы крайне не желательно

Почему? Время доступа к файлам шаблонов ничтожно все равно.

shooter93 ★★ ()

Представь (а точнее – пойми), что однажды ты захочешь сделать редизайн. Большой ли, косметический ли. И для него на какое-то время захочется уйти с головой в вёрстку, вылизать внешний вид страничек, а затем уже вернуться в код и проинтегрировать темку с ним обратно. Вот тут-то ты и увидишь что гораздо лучше иметь index.html, худо-бедно открываемый в браузере, нежели только index.php, в котором ошибки вёрстки будут перемножаться на ошибки кода и реально мешать делу.

Я сам ненастоящий верстальщик (и к тому же не PHPшник), но в своём проекте отделяю единственную тему от кода именно по вот этой причине.

P.S. Пользоваться некомпилируемым языком @ жаловаться на обращения к ФС. Ну кэшируй, чё.

greatperson ()
Последнее исправление: greatperson (всего исправлений: 1)
Ответ на: комментарий от Kilte

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

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

Нет правильного и неправльного подходов. Решение подбирается под конкретную задачу. И решение, подходящее для мегапортала не самое лучшее для HelloWorld веб страницы. Поэтому начинаешь с самых простых способов решения конкретной задачи, а когда задача усложняется, переходишь на более сложные инструменты.

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

anonymous ()
Ответ на: комментарий от anonymous

Рано ещё Спуфингу такие вещества курить…

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

Deleted ()
Ответ на: комментарий от Deleted

на server-side дает неплохую производительность, насчет браузеров да, заброшено

anonymous ()
Ответ на: комментарий от anonymous

Нельзя дебилам предлагать XSLT. Там же функциональщина, он вообще поедет головой

boombick ★★★★★ ()

Возьми в руки доки по Yii2, Laravel, Symfony и вперёд. Изучай как делают приличные люди. Не городи странные и непонятные велосипеды. Всё равно обосрут все и никакой пользы не будет.

Ну или хотя бы с CodeIgniter начни, а потом перелезай на три вышеозвученных фреймворка.

И не вороти нос. Хоть научишься более или менее что-то разрабатывать на PHP по нормальным канонам.

resurtm ★★★ ()

Ты веб-разработкой зарабатывать планируешь или развлекаешься?

Это серьезный вопрос

JANB ()
Ответ на: комментарий от JANB

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

Spoofing ★★★★★ ()
Ответ на: комментарий от Spoofing

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

Раз сам для себя ставишь условия - значит развлекаешься. Ну развлекайся))

Если очень нужна надежность в плане паранои (ты же не доверяешь готовым решениям) - смотри в сторону octopress, в этой штуке вообще нет php и прочих скриптовых языков торчащих наружу. По сути, в ней нет уязвимостей, потому что это статика. http://habrahabr.ru/sandbox/64177/

JANB ()

public function HTML

Вот так точно делать не стоит. Вы намучаетесь.

Главный шаблон лучше вынести отдельно в полноценный html, а позже его подключать. Или подключать движок в него.

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

ob_start(); include $this->theme; return ob_get_clean();

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

но пугает множественное обращение к ФС и мелким файлам.

Просто вы немного не с той стороны смотрите. :)

Не надо подключать каждый шаблонный файл. Достаточно иметь шаблон с переменными с HEREDOC:

$POST_TPL = шаблон;
$COMMENT_TPL = шаблон;
$COMMENT_FORM_TPL = шаблон;

Задача написать один единственный блог

Тогда это более, чем подходящий вариант. Пишите код, выносите основной шаблон в отдельный файл, а шаблоны постов/комментариев в шаблоно-include. :)

lexazloy ()

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

Если вы хотите видеть весь свой проект в одном файле, то зачем вам вообще нужен ООП? Вы просто не можете понять саму концепцию. Если у вас есть модель Comment и модель User, зачем вам это хранить в одном файле? Когда вам нужно изменить модель авторизации, вы уже знаете какой файл вам нужно править, какой метод, и даже какой блок кода и вам нет необходимости постоянно бегать в поиск.

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

Как правильно сказали выше - если вы делаете это ради развлекухи, то не имеет смысла забивать себе голову, может она вам понадобится в других начинаниях. Но если вы серьезно настроены работать в этой сфере, вам просто придется начать учиться=) Как говорится век живи, ну дальше знаете. Завтра вы зададитесь задачей написать поиск с учетом ошибок, и будете городить неслыханные огороды, даже может быть никогда и не узнав о каких-то там, допустим, дистанциях Левенштейна и иже с ними. В дальнейшем вы будете тратить безумно огромное количество времени на решение простых по сути задач. Эта сфера такая - здесь самоцель - не деньги, здесь самоцель - обучение. По крайней мере так это для меня=) Поэтому делайте уже выбор. Я думаю по качественной литературе, вам обязательно здесь подскажут. Ну и разумеется english, sir =)

znenyegvkby ()

От себя бы порекомендовал начать с паттернов проектирования, чтобы стала яснее сама идея. По паттернам стоит почитать design patterns «банды четырех». Хоть это и попса, зато в оригинале действительно идею освежили. Мне нравится сама идея абстрагирования задачи от ЯП. Здесь это передано достаточно хорошо, хоть для примером и используются конкретные языки. Конечно же, я советую читать в оригинале, т.к. с переводами тех. литературы у нас в стране реальная напряженка. Очень часто путаница в терминах, отчего у людей в голове образовывается в конце концов полная каша=)

znenyegvkby ()
Ответ на: комментарий от Kilte

Вот, например: https://github.com/thephpleague/plates

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

A1 ()

man DI, SOLID, DRY, YAGNI

anonymous ()
Ответ на: комментарий от znenyegvkby

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

ktan ★★★ ()

Так как ты сделал в стартовом - не делай!!!

Почему не делать:

1) оно не читаемо

2) легко допустить ошибку в верстке)) и ничто тебе не подстветит в IDE

3) обслуживать это - пипец

4) прикинь ты захотел менять темы (утром одна, вечером другая, днем третья)

Рекомендую:

1) шаблон в отдельном файле( натив или шаблонизатора - сам решай)

2) структура максимально разбита, но потом собирать и кешировать

3) сразу думай о кешировании!!!

webmak ★★ ()

Ты точно уверен, что понимаешь, для чего нужно ООП? В заглавном посте полная дичь даже для студента-первокурсника.

CatsCantFly ()

Не смешите.

тут я угадал автора

q11q11 ★★★★★ ()

логически постарался их отделить в HEREDOC.

Нет. Хтмля в пхп-файле не должно быть. Вообще. Совсем. Никогда. Запомни это. За такое в приличных конторах увольняют. У фс есть кеш, так что об обращении к диску не волнуйся. Вынеси всю верстку в отдельные файлы и подключай при помощи уже существующих шаблонизаторов типа twig или smarty. Второе не рекомендую, ибо это монстр, возможности которого ты не используешь и на 5%, зато притащишь в проект килограммы говнокода.

eval

Забудь это слово как страшный сон и никому его не говори. Эвал - это как goto в С - лучшый способ выстрелить себе в ногу и наделать фатальных уязвимостей.

хочу написать _весь_ проект в одном единственном PHP-файле,

Убейся! Пожалуйста, убейся!!

drull ★☆☆☆ ()
Последнее исправление: drull (всего исправлений: 3)
Ответ на: комментарий от Spoofing

Один класс - один файл. Это правило хорошего тона, упрощающее чтение кода. Исключения - это _пустые_ классы эксепшенов в конце файла с классом, которые кидаются только в этом классе.

drull ★☆☆☆ ()
Последнее исправление: drull (всего исправлений: 1)

Да, если так волнуешься насчет производительности - посмотри в сторону фреймворка phalcon: https://www.phalconphp.com/ru/ . Он компилится как модуль пхп, за счет чего работает быстрее обычных «файловых» фреймворков.

drull ★☆☆☆ ()
Ответ на: комментарий от drull

Исключения - это _пустые_ классы эксепшенов

Исключения из правила в смысле. А то тавтология вышла :)

drull ★☆☆☆ ()
Ответ на: комментарий от drull

Это же spoofing.

У фс есть кеш, так что об обращении к диску не волнуйся.

Ресурс диска же!

anonymous ()
Ответ на: комментарий от drull

Хтмля в пхп-файле не должно быть. Вообще. Совсем. Никогда. Запомни это.

Как не может быть хтмл в шаблонизаторе-переростке? Пчелы против меда.

За такое в приличных конторах увольняют.

Ты же там не был чтоб так говорить.

goto в С - лучшый способ выстрелить себе в ногу и наделать фатальных уязвимостей.

А Путин закусывает грудничками.

A1 ()

Блин, не могу. Каждый раз кровавые слёзы наворачиваются, когда читаю лапшу на php.

Hertz ★★★★★ ()
Ответ на: комментарий от A1

Как не может быть хтмл в шаблонизаторе-переростке?

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

drull ★☆☆☆ ()
Ответ на: комментарий от A1

Ты же там не был чтоб так говорить.

У тебя плохой навык телепатии, прокачивай дальше.

drull ★☆☆☆ ()
Ответ на: комментарий от A1

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

drull ★☆☆☆ ()
Ответ на: комментарий от drull

Где ты видел хтмл в коде того же смарти?

PHP это шаблонизатор, чтоб ты там не фантазировал: https://github.com/search?l=PHP&q=div&type=Code&utf8=

У тебя плохой навык телепатии, прокачивай дальше.

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

A1 ()
Ответ на: комментарий от drull

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

А как с тобой можно конструктивно говорить? Ты пишешь на шаблонизаторе и похоже тебе это нравится.

A1 ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.