Форум сайта MyRusakov.ru

Михаил, я знаю, что вставка html в php это очень плохо..
мое:
<?php УЗНАЕМ ПЕРЕМЕННУЮ echo текст текст ПЕРЕМЕННАЯ текст текст ?>
нужно переписать как:
текст текст <?php УЗНАЕМ ПЕРЕМЕННУЮ echo ПЕРЕМЕННАЯ ?>текст текст
но всё равно я не понимаю как потом этот код ужать в вид:
текст текст {$вывод переменной$} текст текст

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

Я напишу в пятницу про использование tpl-файлов, может быть, тогда поймёте.

благодарю! а я пока снова перечитывать основы php

С этого и надо было начинать. Без ООП не стоит вообще за это браться. Можно даже сказать что пока не знаешь и языка.

Это мой самый первый пример)


<?php

class tplShab {
public $locationSite;
public $contentbody;
public $theme;

function reptpl() {

$this->locationSite=intval($_GET['reg']);

$connect = mysql_connect ("localhost","ssbug","q1";
$select = mysql_select_db("ssbug";
$result=mysql_query("SELECT `content`,`id`,`theme` FROM `user` ";
while ($dump=mysql_fetch_array($result))
{

if ($dump['id']==$this->locationSite) { $this->theme=$dump['theme']; $this->contentbody=$dump['content'];}

}

if ($this->locationSite>10) { header('location: http://test1.ru/index.php?reg=1'); }

}

function themes() {

echo $this->theme;

}

function contentout() {

echo $this->contentbody;

}

}

?>


Здесь я вывожу информацию по номерам страниц.
На главной же просто вызывал метод
include("/llll/ll.php"
tplShab::reptpl();

Конечно многое здесь не совсем верно, правильнее было бы определить параметры запроса к бд как приватные переменные через конструктор. И вообще создать один файл, в нем определить различные классы, проверка, авторизация,запрос к бд, вывод шаблонов, как методы и вызывать все через этот класс. Ну тут я только начинал экспериментировать)

include("constr.php";
con::reg()
con::menu()
И в таком же духе. Да, и так как переменные объявлены как публичные - их так же можно выводить на общей странице в любом месте. Т.е этот класс выдергивает с бд название темы и какой то контент по тому, какой ид в GET.

ппц. потом попробую разобрать этот пример у себя попозже

Не ППЦ. Он элементарен до примитива.

Создаешь файла index.php, создаешь в нем ссылки типа index.php?id=1
index.php?id=2
index.php?id=3

Создаешь в базе данных таблицу. id,theme,content.

Создаешь файл config.php.
В нем пишешь примерно следующее.
class conf {


function reg(){

include("regGet.php";
filtrGet::page();

}

}

В файле regGet.php создаешь класс filtrGet, с методом page,проверка get и вывод соответствующей информации из бд данных.

Далее на index странице подключаешь файл-конфиг и вызываешь из него метод нужного класса.

include("config.php"
conf::reg();

И все. ты щелкаешь по ссылке, в GET Передается id=1, т.к ты вызываешь метод reg класса conf, который в свою очередь является подобием метода для класса filtrGet - у тебя происходит обработка гет запроса. Т.е
основная страница->конфиг->проверка GET
->метод регистрации
->метод стилей
и т.п


Вот немного о шаблонах. Думаю Михаил против не будет.
http://open-classroom.net/php-lections/3579-ispolzovanieshablonovvphp.html

Мне лично такие подходы вообще не нравятся. Лаконичнее и аккуратнее просто определять переменные через методы значениями из бд и вызывать их на indexной странице в определенном скилете html в нужных местах. Здесь уж как тебе будет удобно, многих и парсинг устраивает,но понимать нужно все равно разные подходы.

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

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

Первый вариант- это парсинг tpl файла с подменой определенных заданных для шаблона строк на их определенные значения с бд. В этом случае нам нужно подключить файл- шаблонизатор который считывал бы файл-html скилета, делал запрос в бд определяя заданные строки их значениями.
Можно конечно сделать сам шаблонизатор на index странице, но все же, я считаю что лучше будет вынести его в отдельный модуль. Как пример :


На index странице
include("tpls.php";
clTPL::in();


Сам файл tpls с классом парсинга Файла tpl и методами его вывода.


tpl:

<head>
<title>{tit_tpl}</title>
</head>
<body>
{content_tpl}
</body>


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

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

Важно соблюдать модульность. Важно понять значение и важность модульности.



Ну и вообще замечательно если класс шаблонизатора будет входить в общую "библиотеку" классов. Т.е в файл, который будет вызывать все модули и из которого мы сможем выборочно выводить информацию на index страницу. К стати так проще будет организовать админ панель сайта.
index ---> config.php
<--- \---->класс регистрации
---->класс шаблонизатора
--->класс чата


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

include("config.php";

<head>
<title>tpl->title();</title>
</head>
<body>
tpl->content();
</body>

и т.п

Int, смысл обьяснять, как строятся tpl??? если человек не хочет прочитать уроки, которые есть на сайте? Он спрашивает, как ему вывести то, если вот так, а так, если то. Если человек даже не знает, что такое условные операторы, куда ему там объяснять про ООП??? Очень рано ему это. Основы и ещё раз основы ему нужны)))Так что ещё рано ему даже про tpl думать, базы нет)))
P.S.: Перед шаблонами нужно понять, что такое инкапсуляция, и для чего она применяется)))

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

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