Статьи

PEAR :: HTML_Template_Report Draft

Интересный черновик предложения для PEAR прямо сейчас среди пакетов предложенийHTML_Template_Report . Статус проекта означает, что автор заинтересован в том, чтобы получить отзыв о предложении в качестве потенциального пакета PEAR — в настоящее время ничего не исправлено.

Думаю, это интересная идея — для меня то, что предлагается, — это что-то вроде электронной таблицы — вы начинаете с необработанных данных (таких как набор результатов базы данных), а затем трансформируете / агрегируете их в документ, который могут использовать люди.

Думаю, это связано с тем, что мы обсуждали на форумах Sitepoint Advanced PHP вопрос о том, являются ли приложения PHP основанными на данных? , Один особенно поразительный комментарий от Джеффа ;

{в PHP… типичным «потоком» запроса является DB> Query> Transform Data> Render to Browser. Данные должны как можно быстрее добраться до финальной стадии, поскольку отсутствует механизм их хранения в памяти.}

думайте об этом как о документе, и, возможно, это будет иметь больше смысла. «Документ» может быть данными. Документ не должен означать производную XML / SGML.

Например, в WACT интерфейс пространства данных представляет документ в формате «переменные PHP». Ассоциативные массивы PHP создают довольно гибкий «документ». В WACT классы базы данных генерируют пространства данных. Шаблоны / Представления используют пространства данных. Контроллеры (действия) преобразуют пространства данных.

Преимущество архитектуры на основе документов по сравнению с архитектурой OO заключается в слабой связи между компонентами.

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

(О, мэйнфреймы уже давно работают с документами. Они называют свои документы сообщениями, а программное обеспечение — ориентированным промежуточным программным обеспечением.)

Думая в терминах «документов» таким образом, думайте, что возможно создать полезные библиотеки для общих «преобразований» документов, несмотря на то, что первоначальное впечатление предполагало, что «общих позиций» будет недостаточно.

Отчасти это происходит из моего собственного опыта с PEAR :: Calendar, как упоминалось здесь

Используя мой собственный пример PEAR :: Calendar, я не смог найти класс календаря, который был абстрагирован от вывода (HTML) и / или хранилища данных (обычно таблицы MySQL). PEAR :: Calendar вычисляет структуры данных календаря (массивы PHP), оборачивая их в объекты, которые предоставляют API, который полезен при создании календаря в HTML (а документы типа XML обычно отображаются в последовательности), как в этом примере . Он сильно зависит от декораторов, чтобы добавить функциональность. Есть некоторые области, где это может быть умнее (например, ленивая оценка структуры данных, в отличие от текущего метода build ()), но, в общем, думаю, что это «работает» для PHP (и я думаю, мне повезло с дизайном хотя вы можете не согласиться). Я не думаю, что PEAR :: Calendar подойдет для среды, где она сохраняется в памяти и может стать фокусом приложения календаря. Для начинающих API доступ к коллекции объектов календаря слишком ограничен (хотя это может измениться), и сохранение целостности структуры данных календаря (например, дней в месяце), вероятно, будет проблемой.

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

Согласитесь с автором, что имя нужно изменить — возможно, что-то вроде «Document_Aggregate» или «Document_Report». Кроме того, из поверхностного взгляда на код , есть некоторые сомнения по поводу дизайна.

Отчет основного класса, кажется, делает слишком много (там уже есть функциональность, связанная с валютой и датой — подождите, пока кто-нибудь попросит i18n…). Подход «обратного вызова» может хорошо работать для этой проблемы, но должен поддерживать методы объекта, а также встроенные функции PHP IMO.

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