Прогнозирование набора необходимых шаблону данных [php]
news.php
...
$fields = $t->wanted_vars_by_group('news_record');
...
if (is_array($fields) && count($fields))
{
$q = sprintf('SELECT %s FROM `news` ORDER BY `news_date` LIMIT 15',join(',',$fields));
...
$t->set('news_records',$news_records);
}
...
На что следует обратить внимание, ради чего я привел код. Верстая движок, а если точнее, то ту его составляющую, какая отвечает за вывод, не знаю как другие, а я постоянно сталкиваюсь с выбором: заверстать простенькую либу для обработки шаблонов (к примеру, если функционал практически никакой и не нужен), или же использовать какое-то решение со стороны. Так вот, есть множество критериев отбора подходящей либы для каждого конкретного случая, а тут меня в очередной раз забеспокоил один вопрос, решения которого мне еще не попадалось, и на этот раз хотелось бы его решить, а не оставлять до лучших времен.
Разглядывая всячески сторонние работы (имеются ввиду движки) я обращал внимание на то что нередко (или даже часто.. так сразу не скажу) движок выдает данные шаблону в каком-то усредненном (а бывает и вовсе в полном) объеме, то есть выдает всю имеющуюся информацию, информацию которую было бы логично использовать в конкретном шаблоне в том или ином случае, или же минимальный необходимый набор. Так вот, чтобы движку выдать информацию, ее нужно сначало (fixed: сначала) откуда-то получить (из бд, файлов или откуда-то еще), или же сгенерировать на основе чего-то, а потом может еще и обработать под конкретные условия. Все это тратит время и ресурсы, как впрочем и должно быть. Но вот зачем выбирать из той же таблицы в бд все, ну скажем 30 полей, когда шаблон использует из них только два??? Тем больше потери, чем сложнее, объемнее и т.п. и т.д. выборка/чтение/другое и последующая обработка данных. Конечно, шаблоны правятся отнюдь не каждый день, но все же правятся. Можно избегать таких ситуаций, как я описал, с помощью установки в правда/ложь всяческих флагов и т.п. и т.д., но, IMO, такие вопросы должен решать сам шаблонизатор.
Вообще пишу я это просто чтобы узнать ваше мнение на этот счет, потому как может я просто перегрелся и выводы мои бредовы. Надеюсь этот вопрос будет интересен кому-нибудь еще кроме меня, или же, если его уже давно, в глобальных масштабах, переложили с ребра набок, кто-нибудь укажет мне правильный путь=)ъ
Да, есть у этого метода одно ограничение, правда выявил я его только на первый взгляд, и может проспавшись окажется что оно не действует, но все же. Шаблонизатор должен поддерживать работу с шаблоном на промежуточной стадии, после парсинга, но до непосредственно вставки в него данных.
Мне чаще попадались шаблонизаторы, НЕпозволяющие работать с шаблоном в такой манере, хотя на perl'е все было с точностью до наоборот. Но это ладно, пока мне просто интересно, кто что думает по поводу этой "проблемы". Ppl, жду ответов;)
Решаю это дело преобразованием тега из шаблона в вызов функции.
<tag_name attr1='...' attr2='...'>
content
</tag_name>
приводится к вызову функции std_prefix_tag_name(array(attributes), content);
и там тонкости с регистрацией, фильтрацией входных данных, кэшированием.
Надо расширить шаблоны - пишем функцию, пишем регистратор, регистрируем в менеджере и используем новый тэг. Удобно!
Крик души? =) Я правда не совсем понял что ты под модулем подразумевал, шаблон или раздел?:D
Навигация это модуль. Функция форматирования статьи получающая текст, заголовок, эпиграф и прочее - модуль. Подсветка синтаксиса кода модуль(практически уже написанный)
По ситуации. Если результат работы функции зависит от комбинации входных параметров(GET/POST запроса), скажем file и user_id, то эта функция(модуль) при регистрации сообщает об этом. Соответственно кэш будет идентифицироваться комбинацией значений этих параметров. А для модуля подсветки можно брать хэш от входной строки. То есть приходим к тому что либо модуль описывает процесс идентификации кэша стандартными методами менеджера, либо регистрирует в менеджере функцию, отвечающую за выдачу id кэша для данного вызова. Причем стандартные методы менеджера можно также сделать модульными и реализовать через регистрацию подобных функций, просто доступных по дефолту.
Фильтрация данных -тоже модульная. Многие данные фильтруются стандартно - числа, значения для свича из заранее известного множества, данные используемые в SQL запросе, в общем с известными и часто употребляемыми методами фильтрации. Создаем модуль фильтратор, который сам является модульным и каждый его модуль соответствует определенному правилу фильтрации. Часть правил доступна изначально. При регистрации модуля менеджера оный сообщает какие параметры запроса он использует и какими правилами их следует обрабатывать. Если имеющихся правил не хватает, то сначала регистрируются требуемые правила, затем уже собственно модуль.
На самом деле это у меня достаточно подробно расписано по чероновикам, есть куски кода, есть модуль подсветки(я за него уже упоминал на форуме) Постоянно появляются наработки, недавно вот табы продумал(тоже упоминал на форуме), готовлю к реализации. Если есть желание, могли бы неслабый контент менеджер задвинуть с системой шаблонов интегрированный. А то одному как то скучнова-то.
Да у меня заверсток толком нет, я только планирую=) А реализация [планируется быть] подвязана к какому-нибудь языку?
Реализация планируется такой, что проект сверстанный под этот контекст менеджер будет работать под любой реализацией ЭТОГО контент менеджера. А реализации планируются на php/perl и ASP[JS]
перло-пыховая версия с MySQL и PostgreSQL - бесплатная. Модули для работы с другими базами - платные. ASP версия платная изначально. Бесплатная версия даст внимание к проекту и поддержку в плане мозгов, идей, модулей от сторонних производителей, обкатку и прочая инфраструктура. Платная версия дает монету как для поддержки проекта в целом так и для намазывания масла с черной икрой на бутерброд для ведущих программистов. :D
гм. а может jsp получше asp'а будет?:)
Одно другому не мешает.
А я хз. Посуди сам. Получаем голимый html/xml со своими тегами. Можем добавлять новые, но не как в xml, а регистрируя в менеджере. С этой точки зрения - голимый движок шаблонов. Однако окружение, в котором работает скрипт-модуль - голимый cmf если я правильно понимаю терминологию. Однако админ панель(которая тоже модульная и нормальный модуль, имеющий параметры управления своей работой регистрирует их и автоматом получает кусочек места в админке) предоставляет готовые средства для управления модулями, идущими в поставке, как то - форум, новостная лента, бла, бла, бла. То есть cms в чистом виде. Вот и попробуй теперь ответить на свой вопрос :D
Просто, imo, первое важнее. Cms-то множество в паутине, а далеко не все даже отдаленно напоминают единый механизм, а значит расширяемость идет в комплекте с геморностью, причем чья доля больше это еще вопрос=)ъ
Сугубо личная заметка=)ъ
Кстати достойная реализация cmf, где perl'у отводится ведущая роль это уже чуть-ли не моя мечта)
Для меня это ключевой момент в реализации менеджера. То есть не реализация на перле, а развязка(по возможности) от языка.
имхо, при выборе средств построения проектов в сети, нормальный человек предпочтет при прочих равных то, что позволит ему безболезненно сменить как язык реализации так и платформу.
На данный момент единственный серъезный камень что я вижу - это работа с базами.
Сразу в голову полезли мысли по единому механизму отлова и последующего вывода ошибок для всего cmf вцелом. Есть какие мысли на этот счет? Сразу вспоминается отсутствие в php4 деструкторов и один единственный выход - register_shutdown_function, который никак нельзя назвать изящным. Perl тут rox=)p Классификация ошибок различного рода, адекватные действия в ответ на их возникновение и т.п. и т.д., способы подачи в приемлимом виде ошибки возникающие в процессе создания инстанции cmf'а и ошибки в конечных модулях или где там.
И кстати, а какую версию php использовать планируешь, или вопрос уже давно так не стоит? Меня оно, 5.x, не очень воодушевляет. Может я неправ?:)
Сразу в голову полезли мысли по единому механизму отлова и последующего вывода ошибок для всего cmf вцелом. Есть какие мысли на этот счет? Сразу вспоминается отсутствие в php4 деструкторов и один единственный выход - register_shutdown_function
Ну зачем так сразу?
Error Handling and Logging Functions
вполне очень даже ничего. Просто свои обертки нужны для работы в среде менеджера.
И кстати, а какую версию php использовать планируешь, или вопрос уже давно так не стоит? Меня оно, 5.x, не очень воодушевляет. Может я неправ?:)
Меня пятерка тоже особо не возбуждает, но не потому что не нравится, просто я ООП юзаю крайне редко и только при необходимости. Подавляющее большинство задач которые передо мной встают решаются на функционале гораздо проще и яснее чем классами. Но я не противник ООП, просто у меня свои взгляды, где оно надо, а где не очень.
На девелоп-машине четверка стоит, у хостера вроде тоже не переставляли.
P.S. sql.ru починили, я как всегда опоздал :D
o----------------------------------------------o
| |
| |
| Editable region Toolbar |
| o-------------o o------o |
| | | |InsImg| |
| | | |InsTbl| |
| | | |InsFrm| |
| | | | ... | |
| | | | | |
| | | | | |
| | | | | |
| o-------------o o------o |
| |
o----------------------------------------------o
Что-то типа того.. )ъ Трабла пока в том, что onmouseover event хоть и дает ссылку на элемент с коордиантами которого у мыши в данный момент есть общие точки, но пользы от этого нет, так как пока тащишь ту же картинку и курсор естесно висит на ней, то целью эта же картинка и является. Вот голову ломаю, либо самому отслеживать место назначения рекурсивным перебором по всей dom модели, либо найти такой вариант захвата элемента для d&d, когда без особой порчи внешнего вида курсор будет всегда вне таскаемого элемента, но не будет создавать лишних траблов. ДА, можно еще onmouseover (или другой подходящий) эвент прицепить ко всем элементам макета редактируемой страницы, но.. это ж какие тормоза будут, думаю IE сразу вышибет, как и NS +)
Есть идеи?;)
И по поводу поиска еще. Поскольку толком этим не занимался, и ничего по этому поводу не читал/изучал, то представления довольно расплывчатые.. о механизмах этого дела=) Жуткие трения со всех сторон при попытке интернационализации чего-нибудь пугают, даже та же долбаня регистрация какого-нибудь юзера в какой-нибудь долбаной борде.. Если метить на несколько государств, ну, не СНГ, а к примеру Россия, США, Кения.. и т.п. Так вот, даже те же фио, имхо, обязательно нужно подгонять. Не понимаю англоязычных разработок, где кроме first- да lastname ничего не просят, это какое-то неуважение к нашим отцам что-ли. Если так где-то принято, то оно должно быть реализовано!=) А у негров (непомню с какой части света) в отчествах еще и деды отмечаются, а может и более дальние родственники.. Как со всем этим быть?:) И если с юзерами такая лабуда, то что же тогда твориться с запросами, которые эти самые юзеры тыкают в лицо поисковику.
Да, и опять же, самая длинная фамилия в мире. До сих пор беспокоит та что за 1,5 тыс. символов, или около того. Вдруг я что-нибудь напишу, какую-нить форму регистрации в ту же поликлинику, ограничу юзеров 40ю символами под фио на каждое и все готово. А этот длиннофамилей попробует зарегиться, ну, на анализы, не сможет ввести свои данные, подаст на меня в суд, меня обуют и посадют за какую-нибудь дискриминацию muchdata'манов. Жуть, страшно, надо как-то выкручиваться=)ъ
Непомню где читал, по-моему здесь же в какой-то статье, про программера пишущего драйвера под аквариумы и топливные баки вертолетов что-ли. Где из-за того, что программер не потрудился заюзать com или как-то побороть траблы с одноименностью своей либы, стал виновником гибели какого-то вертолетчика - любителя рыбок. Очень полезная сказка (а может быль? ^^).
Скинь что-нибудь по поискам, если есть. А-то я себе сразу представил запрос разбитый по пробелам, каждое слово - объект принадлежащий какому-то языку, разбитый на характерные для этого языка части слова и т.п. и т.д... ой как все сложно=)ъ
У меня Opera здесь тормозит (8-ка), IE вообще виснет недогрузившись, а NS (тож последний) работает как часы. В чем соль?:DDD А вообще надо глянуть код, когда у программиста своя субъективнейшая точка зрения на то, какой браузер достоен поддержки и всяческих оптимизаций под него, а какой нет, такие фокусы нередкость.
что-то зачесалось где-то чувство эдакой неполноценнсоти. сколько человекожизней мне понадобится чтобы разверстать подобное дело, если я с имейджами одними только уже сколько вожусь=))
печально:/
http://www.innovastudio.com/editor_tutorial.asp
что-то зачесалось где-то чувство эдакой неполноценнсоти. сколько человекожизней мне понадобится чтобы разверстать подобное дело, если я с имейджами одними только уже сколько вожусь=))
печально:/
Лучше меньше да лучше. Вокруг маленького но хорошо работающего народ соберется, расширит и углубит. А в одиночку тяжеловато. Хотя колхоз дело добровольное.
По поводу поиска - работаю над морфологией, сейчас добиваю генерацию всех форм существительного по его именительному падежу ед. числа и роду.По роду и окончанию определяем склонение и генерим множественное число которое также склоняем. В сети видел подобное, но хочется своего. Добью - выложу - если интересно.
А про поиск выкладывай, будем изучать, может тоже что добавлю ^^, хотя не уверен конечно. Наткнусь если на какую понятную мне книгу по этому поводу— попробую вникнуть. А пока потычу свою эту модель=)