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

4. Не совсем ясно, зачем имя в двоеточиях...

Но вообще эта пять. Если ты только начал, то начало более чем хорошее получилось.
Успехов.

ок. Пересмотрю

cols = "30" rows = "10" Это же задает размер тестового поля. По другому то я не задам его.
Или вы что то другое имели ввиду ?

Перенос строки. Вот так только можно:

Это надо сделать вот так? Или я протупил и надо сделать совсем иначе ?

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

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

Меня давно подмывает сравнительный анализ устроить. Что же всетаки эффективнее ООП или процедурка. Со всех сторон. С точки зрения разработки, скорости, ресурсоемкости, прозрачности и так далее.
Именно для повседневных задач, без выкрутасов. Буду посвободнее, устроим.

И еще

Эт от чего? Глобальная переменная хорошо и очень удобно. Другой вопрос, что она может повредить безолаберности, так она в этом совсем не виновата.

Нет. Не так. Вот так.

Было так изначально, но выяснилось что оно так не работает сделал как процедуру, заработало.. О! вот сейчас обратно вернул и работает

// Вывести все на экран - шаблон
if ($show == true) {
$book = load_data('data.txt');
include "view.php";
display_errors();
}

До ООП в PHP я пока не дошел, так в вкратце представляю.
Просто я сейчас взял тему читать: шаблонизаторы
там на первом месте MVC потом еще пассивный шаблонизатор HTML_Template_IT из бибилиотеки PEAR Потом хотелось бы еще и XTemplate поюзать а в итоге перейти на Smarty.

Пока незнаю применяется ли MVC в остальных шаблонизаторах, как в пасивных так и в активных.

twin, чему учишь? Глобальные переменные это ошибка/привычка, от которой нужно избавляться в самом начале.

не будем сейчас устраивать очередной холивар по поводу ооп-неооп.

WhiteKnight
mvc - это шаблон (или паттерн) проектирования. рядом с шаблонизаторами рядом не стоит по идее. что за книгу читаешь?

twin,
Позвольте мне с вами не согласится.
Простые вещи надо делать просто. Вы можете мне тут возразить, что даже в простых вещах надо закладываться на усложнение. Но тогда какой смысл закладываться на усложнение, заведомо проигрышным вариантом? А я считаю, что MVC, показывает свою мощь именно в ОО реализации.
Почему я так считаю, потому что я как и все кто используют ООП прибегаю к:
наследованию - нигде не дублирую то что общно (ну и куча деталей ещё);
инкапсуляции - специфика работы той или иной разновидности определённого блока, сокрыта и не влияет на способ использования;
полиморфизм - тонкий тюнинг, эдакое undo предоставленного наследованием функционала.

А теперь что у нас есть в MVC.

Нам необходимо, 100% иметь несколько видов отображений (native templates, smarty, xslt и т.д.) и иногда замену одного на другое во время выполнения (например когда в smarty шаблон, дополняется данными сформированными XSLT шаблоном из какого-нибудь мудрёного SOAP запроса).

Что касается контролёра. Вроде всё здесь просто, вроде контролёр одна из структурно не меняющихся частей, однако это тоже не верно. Некоторые неверно понимают роль браузера. Браузер, особенно когда речь идёт о AJAX, тоже становится частью контролёра. Поэтому контролёр, тоже получается у нас для разных ситуаций может быть разным, и иногда с значительным тюнингом наследуемого функционала.

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

Я выразил всего лишь свою точку зрения, как бы обозрев со своей колокольни - зачем я использую MVC, и почему только с ООП

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

Предвижу возражения, что это хорошая привычка, что на больших проектах это незаменимо и так далее.
Так вот, положа руку на сердце, как часто приходится делать такие действительно большие проекты? Стоит ли выполнять 99% своих работ так закрученно, только из за того, что вдруг появится этот самый 1%?

Если чесно, лично мне вообще не приходилось видеть такой проект, который не может работать не по схеме MVC + ООП. Хотя работает куча моих сайтов, у которых около 1000000 посещений в сутки и которые состоят из 20-30 разделов с кучей своих страниц в каждом.
Я видел аналоги на ООП, так они ни на сколько не проще, я бы сказал что на много сложнее.

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

Я повторюсь еще раз - ничего против MVC + ООП я не имею, каждый пишет как он хочет и считает правильным.
Я просто всегда резко против того, что если вдруг находится человек, который строит приложения по своим алгоритмам (как WhiteKnight в данный момент), сразу же появляется множество советчиков, которые начинают объяснять кто редиску под землей красит в красный цвет. Мол надо вот так, потому что кто то придумал , разрекламировапл и внедрил в массы принцип MVC + ООП. Как будто по другому нельзя. Или, что еще хуже - неправильно.

Нет таких стандартов. Нет и быть не может.
А сравнительный анализ я все таки проведу.

да чем же они тебя так обидели то? Какая же это ошибка? Так можно от половины возможностей ООП отказаться, посчитав дурным тоном... Допустим то этой конструкции : $$var, потому что кто то где то сказал, что это плохо. Или от применения eval(), проникшись параноидальным настроением...
Все хорошо на своих местах.

Котеров PHP 5 В подлиннике
Котеров PHP 5 второе издание

Во втором издании тоже есть такая тема.
Не понимаю зачем продают две одинаковых книги, только названия разные

Есть моменты, когда параметры не спасают. При рекурсии допустим. Или когда функция меняет переменную попутно, возвращая совсем другой результат. А глобальная переменная весьмя кстати. Я же говорю - все хорошо на своих местах.

вообщем на компе вот такое теперь



но на хостинге почему то все по прежнему
----------
теперь на хостинге обновилось.

а из этой функции убери обработку тобишь

http://php.inkz.ru/guest/index.php?a=4

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

Так же и с рекурсией. Тот же счетчик. Параметром его не передать, да и не вывести показания просто так. Вообще много чего можно. Ты просто привык к своим $this-> а это практически тоже самое.

можно параметром, можно и не параметром. скажем, а что будем делать, если посчитать нужно не только запросы, но ии... обращения к файлам через какую-нить функцию?

с глобальными мы будем вводить $countDb, $countFile и прочие ужасные вещи.

с параметром:

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

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

Db::$count
File::$count

если пойти дальше и абстрагироваться от конкретного класса, то со счетчиком можно организовать работу на абстрактном уровне, не ориентируясь на емя переменной ($count, $countFile, etc).

откуда такие выводы? НИКОГДА не гружу все - всегда только то, что нужно и ничего лишнего.

представляю как представляю - естественно могу ошибаться.

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

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

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

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

перед этим

Выполняют они одно и тоже, только
а. Что бы узнать что именно делает эта проверка в первом случае, нужно сходить в класс и поискать там этот метод.
б. Не нужно загружать остальной функционал, если требуется только эта проверка во втором случае.
в. объём кода во втором случае меньше, чем в первом.
г. Синтаксис второго варианта понятен большей части разработчиков, так как не все ориентируются в ООП.

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

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

Поехали дальше. Если у тебя на странице несколько разных проверок и обработок, ты грузишь несколько классов, выдергивая из каждого по одному - два метода. Допустим при авторизации ты вызываешь класс User(), методы которого определяют его идентификатор, имя, возраст и еще кучу параметров. А нужен всего навсего его телефон.
Ты загружаешь весь класс, со всеми его методами. И в итоге у тебя уже гора излишнего функционала, который присутствует в данном сценарии и который совсем невостребован. Так вот, в том месте, где это все собирается в кучу (а там допустим 10-15 методов и каждый из разного класса) у тебя только вывод. То есть вызов методов. А чтоб получить общую картину того, что происходит в данный момент, ты должен перелопатить все эти классы (а они как правило в разных файлах) и (в голове!!!) представить себе текущий сценарий.

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

Я формирую функционал непосредственно в обработчике. Контроллере, если угодно. Используя вспомогательный функционал только там, где он действительно оправдан. Динамически подключая необходимые библиотеки. А если есть возможность обойтись штатными процедурами, не ломаю голову над тем, как и куда их упрятать, что бы не дай Бог не нарушить концепцию. Просто применяю их прямо там, где им и место.

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

Если чесно, я ничего не понял, что именно подключить и чего подсчитать?

А я и не говорил. Я говорил о том, что я его там же и определяю, где он мне нужен. И не бегаю в класс. У меня страницу формирует один файл, а общий функционал подключается при надобности.
И доводы не те у меня. Это ответ был на то, что ты сказал:

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

Лан, всё. Я потом все равно сравнительный анализ сделаю.

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

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