Pull to refresh

Comments 36

Что-то не совсем понятно как вы обошлись без include'ов?
#include /repository/stream.php;

Парсер подменяет данную конструкцию сразу на содержимое файла.

Ну а если контейнер, необходимый для инклуда содержится прямо в «основном» файле, то просто
вызываем этот контейнер <class::stream>
Если я все правильно понял, то что бы отделить еще html от php, нужно будет 4 файла?
Можете привести пример разделения html, от php?
На рисунке примерно такая схема реализована без создания файлов.
Когда html отделяется от php вообще, я не вижу где у вас хранится выборка с базы данных к примеру. Или вы это пишите в index.php?
Пример:
pastebin.ru/301151
Бизнес-логика в <meta.index>, html шаблон вывода <strict.index>, затем всё это вставляется в основной шаблон для всех страниц <area.simpleTemplate>
Какая-то жуткая мешанина..php+html + еще какой-то метаязык разметки. неясно зачем.
Решение может и интересное но не совсем понятное :)
Аналогично. Много текста о теории и всеравно не понятно что же делается. Может стоит пошагово расскать что же вы делали?:)
Да, чуть позже расширю статью :)
Я так понимаю, предлагается компилятор кучи исходных текстов в один по каким-то схемам (xml, etc)?
Всё равно не понятно, как тогда в большом проекте будет запрещаться дублирование функционала. Пример бы.
Чето какие-то ветряные мельнцы. Вы с инклудами боретесь потому что они долго подключаются? Дак они компилируются в этот момент. Пользуйтесь еАкселератором или аналогичными решениями, все подключается в разы быстрее.
Насколько я понял основную концепцию — в общем и целом это похоже на макросы в С/С++.
Т.е. вы пишите некие переиспользуемые структуры, и включаете их в разные страницы, а при «компиляции» включения просто вставляются текстом. Т.о. при изменении одной из переиспользуемых структур нужно будет пересобрать все страницы.

Идея чем-то интересная. Доведите до ума и можно будет посмотреть будет ли оно себя оправдывать на практике.
Альфа версия парсера уже написана, на ней работает сейчас 2 «подопытных» сайта (sevlux.net и nouts.net смотреть исходники HTML в самом низу дебаг строка).
Проекты небольшие, по времени генерации страницы, и затратам памяти:
pageGenTime:0.00451 sec. memoryUsage:238.34375 Kb
pageGenTime:0.00801 sec. memoryUsage:440.703125 Kb
> memoryUsage:238.34375 Kb
> memoryUsage:440.703125 Kb

Ого, прям до миллибитов :)
Жаль что незнаком с макросами в C/C++. Сейчас почитал, и понял что необходимо развивать в этом направлении.
Расскажите что значит ваша разметка, что такое sincous, page, area, unicate и т.д. Это конструкции с разным поведением (лексемы языка) или это имена классов? Если лексемы, расскажите чем они отличаются, если имена классов покажите сами классы.
Ей-богу, шарада какая-то :)
page — это названия классов для страниц. Можно использовать любой свой префикс (всё настраивается в скрипте). При компиляции страницы index (или какую вы указали) будет выборка <page.*> (где * — это название страницы). Структурные блоки также настраиваемые.
Можно написать например [!page.index] и т.д.
sincous, area, unicate — классы можно назвать произвольно. Я так назвал, только ради подсветки синтаксиса «неправильных» html тегов в Zend Studio.
я так понял вы все остальное в мире уже оптимизировали и теперь сайтом занялись?
Скорее наоборот :)
Начал заниматься сайтом и оптимизировать всё остальное.
Расширил статью, написал о основных синтаксических конструкциях и глобальных правилах.
Изврат какой-то. Для чего… непонятно.
> Некоторые веб-мастера вообще не представляют, какой код у них хранится и начинают писать заново те >функции, которые похоронены в глубине сайта.
Если только для таких веб-мастеров…
>> Часто приходится сталкиваться с тем, что необходимо срочно внести некоторые изменения в сайт, но при этом, редактируя самые важные области,
отвечающие за соединение с базой данных или другим критическим частям сайта, Вы совершаете ошибку и сайт встречает новых посетителей унылым дизайном (в лучшем случае) или полным отсутствием содержания.
Видел пока что только 2 варианта решения этой проблемы:
Редактирование копии файла на одной из скрытых страниц сайта или редактирование сайта на локальном сервере и потом уже загрузка уже работающей модели.
Ну и самый ко ординальный, это редактирование по ночам, когда большей части юзеров уже не до вашего сайта.

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

ЗЫ: кстати был случай, когда деплоем на боевой занимался человек номинально не имевший отношения к компании, можно првести анологию с удаленным одмином.
>>php файлы чаще всего хранят прямо в корне сайта, и поддиректориях, и абсолютно не поддерживают порядок.
Некоторые веб-мастера вообще не представляют, какой код у них хранится и начинают писать заново те функции, которые похоронены в глубине сайта.

с такого проекта надо валить и очень быстро
UFO just landed and posted this here
Мдя…
представил свои проекты, по 6-8Мб кода в одном XML-файле.
ппц.
Афтар, не страдайте херней.
Можно разделять и структурировать файлы так, как Вам удобно.
один xml файл может выглядеть так:
#include catalog.xml
#include blogs.xml
#include work.xml
#include repository/global.xml
Вы ведь, кажется, боролись с инклудами? :)
С затратами времени и памяти от инклудов :)
Аналог #include при создании страницы сразу вставляет файл в указанный блок, в отличие от <? include(''); ?>
Sign up to leave a comment.

Articles