An interesting draft proposal for PEAR up amongst the package proposals right now – HTML_Template_Report. Draft status means the author is interested in getting feedback on the proposal as potential PEAR package – nothing is fixed at this time.
Think it’s an interesting idea – to me what’s being suggested is something like a spreadsheet – you begin with some raw data (such as a database result set) then transform / aggregate it into a document humans can use.
Think it relates to a discussion we had in Sitepoint’s Advanced PHP forums asking Are PHP apps fundamentally data driven?. One particularily striking comment there, from Jeff;
{in PHP … the typical “flow” of a request is DB > Query > Transform Data > Render to Browser. Data has to get to the final stage as quickly as possible, given no mechanism to store it in memory.}
think of this as document driven and perhaps it will make more sense. The “document” can be the data. document doesn’t have to mean XML/SGML derivative.
For example in WACT, the dataspace interface represents a document in “PHP variables” Format. PHP’s associative arrays make a pretty flexible “document.” In WACT, the database classes generate dataspaces. Templates/Views consume dataspaces. The controllers (actions) transform dataspaces.
The advantage of a document driven architecture versus an OO architecture, is Loose coupling between components.
Perhaps its the document driven style that fits well with PHP and web development.
(Oh, the mainframe folks have been doing document driven for a long time. They call their documents messages and their software message oriented middleware.)
By thinking in terms of “documents” this way, think it’s possible to build useful libraries for common document “transformations”, despite the initial impression suggesting there wouldn’t be enough “common ground”.
Some of this comes from my own experience with PEAR::Calendar as mentioned here
Taking my own example, PEAR::Calendar, what got me to write it was being unable to find a calendar class which was abstracted from both output (HTML) and / or data store (typically a MySQL table). PEAR::Calendar calculates calendar data structures (PHP arrays), wrapping them in objects which provide an API that’s useful when generating a calendar in HTML (and XML type documents are generally rendered in a sequence), as with this example. It relies heavily on decorators to add functionality. There’s some areas where it could be smarter (such as lazy evaluation of the data structure, as opposed to the current build() method) but, in general, think it “works” for PHP (and I think I got lucky with the design although you may disagree). I don’t think PEAR::Calendar would be suitable in an environment where it persists in memory and may become the focus of a calendar application. For starters API to access the collection of calendar objects is too limited (although that could change) and preserving the integrity of a calendar data structure (e.g. days in a month) would likely be a problem.
In other words although, at first glance, it may seem HTML_Template_Report is trying to bite off a very big chunk, in practice, be being document oriented it could well deliver a useful foundation for building “reports”.
Agree with the author that the name needs changing – perhaps something like “Document_Aggregate” or “Document_Report”. Also, from a superficial look at the code, have some doubts about the design.
The main class Report seems to be doing way too much (already currency and date related functionality in there – wait till someone asks for i18n…). The “callback” approach may work well for this problem but needs to support object methods as well as native PHP functions IMO.
Also think the author is heading for difficulty by building in knowledge of the output format. Why not prepare the report as a data structure and leave it to users to generate output?
Harry Fuecks is the Engineering Project Lead at Tamedia and formerly the Head of Engineering at Squirro. He is a data-driven facilitator, leader, coach and specializes in line management, hiring software engineers, analytics, mobile, and marketing. Harry also enjoys writing and you can read his articles on SitePoint and Medium.