Так ?


так у меня вот что выдаёт

Бурные и нескончаемые аплодисменты

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

Ну а если мне например надо получить и данные из таблицы и сколько записей получится. Два раза запрос писать... с count и без ?

и шаблон не надо подключать сто раз в цикле:

include очень тормозит работу скрипта... здесь мало у тебя объектов.. а будет больше - ощутишь

?>

есть понятие "шаблонизаторы".. никакой нормальный шаблонизатор не использует 100 инклудов, это во-первых.
во-вторых, у тебя уже смешан HTML и PHP, ты не находишь?

Я не пытался отделить php от html.
Если сильно хочется, можете сделать так к примеру:

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

Тогда код может выглядеть так:

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

Настройки этого же файла также легко подкорректировать в случае надобности.

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

Любой "нормальный" шаблонизатор использует регулярки. И так же в цикле. А любая регулярка на порядок медленнее инклюда. Так что не пугай людей пустым мешком.

А вот этого чего все так сильно боятся? Дизайнера вообще мало касаются теги шаблона, его в основном касаются стили. Ну и те теги, которые можно двигать. Имхо очень даже удобнее и практичнее поместить в php такие теги как <tr>, нежели мудрить приладу, что бы вывести их в шаблон.

Вообще с изобретением шаблонизаторов стали подменять понятия. Сами того не осознавая. Разделять надо логику и представление, а не php и html. Логика, это то, с чем работает программист. А соответственно представление - вотчина верстальщика. Так вот не нужны последнему тээрки, если таблица все равно генерится скриптом. Застилизовать он спокойно может остальные теги. (<table>,<td>).

уверен?

я не боюсь это не критика, а констатация факта:

он у него уже смешан

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

замерь время 100 инклудов и 100 регулярок

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

Вопросов нет, в чистом виде медленнее, если как таковые сравнивать. Но только чтобы что то на что то заменить, нужно это что то получить в скрипт. То есть полюбому нужно file_get_contents(), которая сама по себе в 10 раз медленнее, потому что это функция, а инклюд - конструкция. И плюс регулярки, которые скоростью не отличаются. Всяко разно медленнее шаблонизатор будет работать.

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

Также, насколько я помню, если не указать абсолютный путь (как здесь), то проверяться будет сначала наличие файла в include_path, а затем в текущем каталоге (опять + 1 обращение к ФС).

Поэтому здесь все равно будет производительней взять файл через file_get_contents() и сделать простую замену через str_replace() (не надо регулярок!), его здесь вполне достаточно. Именно об этом я говорю. Хотя я уверен, file_get_contents+preg_replace в данном случае тоже отработают быстрее, чем include.

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

Вообще, для простых сайтов, конечно, здесь спор не уместен . Хоть 100 include в цикле - в принципе отработает достаточно быстро, поэтому можно не заморачиваться, но я бы так никогда не делал

Кому интересно, можно потестить:

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