A decorator hey... And so each ReportMetric would return... Hrm. Part of the issue is trying to generate say, a report that lists all the staff members, and their stats for the week along side them all. Ordinarily for something like that, I would just write a big query that selects all the staff members, then joins on to the various tables to fetch the various statistics. I'm considering breaking down those joins in to generic methods that can be called from any "base" query, as in if you wanted to find out how many comments were entered alongside recordtype1, and also have a different report with comments entered alongside recordtype2, then there is an obvious case for code reuse, however... That sounds like it could very quickly get out of control, and I'd end up putting all sorts of conditional stuff in those so-called "generic" methods.
I guess using a chain of objects and a decorator, it would be easy to generate reports with 2 or 3 different separate tables of data displayed on it, ready for them to print out or use however they want. Compiling different lists of reports becomes very easy. Blergh! Maybe I'm over-thinking this. Perhaps my first implementation is pretty much good enough for 90% of reporting needs, and I should just get it written and move on to the next job. On Wed, Mar 25, 2009 at 6:46 PM, keith Pope <mute.p...@googlemail.com>wrote: > Maybe a decorator? You could then start with a base report and build it up. > > $report = new ReportMetricOne(new ReportMetricTwo(new Report())); > > $report could then be processed by a generic reporting class/model: > > $reportModel->generate($report); > > downside = complexity, decorators can be confusing to people ala > Zend_Form :) Though once you get them they are easy > > > > 2009/3/25 Cameron <themsel...@gmail.com>: > > Hi guys, this is probably more of a general OO question than specific to > ZF, > > but I thought I'd throw it out there to see if there's some really good > > solutions out there. > > > > I've written a pretty extensive application in ZF, it's all MVC driven, > uses > > Dojo and AJAX, it's pretty cool, and generic and flexible enough to > easily > > adapt against different databases with different object relationships. > I'm > > pretty proud of how it's coming out so far, despite a few obvious > > shortcomings, but I've gotten to the point where one of the clients using > > this wants a whole lot of reports generated, and that raises issues of > > architectural requirements. > > > > I've been looking at a Builder design pattern, but the more I think about > > it, the more it doesn't really seem to solve many problems - MVC > separates > > the View already, and it ain't no thang to have a different view script > per > > report page. I guess what I'm trying to work out is how best to model the > in > > between bits - the classes between the View and the DB access in the > Model. > > > > My current Models really only have the usual get / insert / list / count > / > > delete methods, with a bunch of private methods for filtering, sorting > and > > ordering the data, and so any complex report queries would need to be > either > > built using these tools in a separate layer, or implemented as extra > methods > > in the current Model classes. > > > > Another thing to consider is user input in these reports, like sorting by > > columns, pagination, date ranges, etc. > > > > I guess the question is one of style and elegance. Has anyone got any > > examples of a good layer between the Controller and Model(s) for > reporting? > > I was basically considering something like this: > > > > A Reports Controller with a whole lot of named Actions that map to the > > various reports we'll build. > > Each Action handles gentle processing of user input and passes it on to > the > > Reports Model. > > The Reports model holds all the ugly business logic, calling queries and > / > > or other Models directly, processing data to a point fit to return back > to > > the Controller. Try and add private methods for standardizing > functionality > > where I can. > > The regular Models mapping against the business objects remain untouched. > > > > My concern with this layout is one of cleanliness, I guess. It seems like > a > > lot of ugly code to put in the one Model. Has anyone seen this problem > set > > solved really nicely? Something like a handful of good generic reporting > > methods that one can implement that map against a significant number of > > typical reporting needs? A particular OO design pattern that suits this > > really well? Something I haven't thought of? > > > > > > -- > ---------------------------------------------------------------------- > [MuTe] > ---------------------------------------------------------------------- >
