OO Design -- Separating Data from Presentation

rkg has asked for the wisdom of the Perl Monks concerning the following question:

Hi, all -

A basic OO question involving separating data from presentation:

I am trying to work out an object hierarchy for a reporting system. I am envisioning a base Report class which is subclassed into various forms of displaying the report, such as HTMLReport, PDFReport, ExcelReport, etc.

I'll have several report objects -- RevenueReport, ReceivablesReport, etc which will take parameters on creation indicating geography, time period, etc.

Here's my question: how do I tell a report (say, an instance of RevenueReport) to render as, for example, an HTMLReport? Creating all the combinations explicitly (RevenueHTMLReport, RevenueExcelReport, etc) is clear code-stink.

On the other hand, passing the render type into the report my $report = SalesReport->new(%args, type=>'HTMLReport') and then making this SalesReport an HTMLReport by pushing 'HTMLReport' onto its ISA array seems even worse.

So I want to separate data from presentation...

so what is the correct way to tell my data object how it should present itself?

Many thanks for clarifying this for me --

rkg

Comment on OO Design -- Separating Data from Presentation Download Code

Replies are listed 'Best First'.
Re: OO Design -- Separating Data from Presentation by adrianh (Chancellor) on Dec 13, 2003 at 02:26 UTC
so what is the correct way to tell my data object how it should present itself? Of course there is never the correct way :-) However, it might help to split the functionality into three layers: Reports - to handle the details of the different report types (RevenueReport, SalesReport, etc.) ReportFormatters - take report objects and provide a format-independent API to their structure (e.g. $rf->header, $rf->content, etc.) ReportRenderers - that take a ReportFormat object and output it in a particular format (ReportRenderPDF, ReportRenderHTML, etc.) So all the report specific information stays in the Report class. All the output-format specific information stays in the ReportRender classes. Hopefully this makes some sort of vague sense :-) Update: Just noticed - this was my 1000th post. Gosh.	[reply]
Re: Re: OO Design -- Separating Data from Presentation by rkg (Hermit) on Dec 14, 2003 at 01:33 UTC
Many thanks, adrianh. I was hung up on asking the Report to render itself, rather than passing the Report object to a ReportRenderer object. Your answer was spot-on, and got me thinking about objects of the form Noun-That-Does-Verb... interesting... makes me think of a gerund in English. Cool. Thanks -- rkg	[reply]
Re: OO Design -- Separating Data from Presentation by pg (Canon) on Dec 13, 2003 at 02:33 UTC
The best way to seperate data from presentation is provided to you for free: XML. XSLT can be easily used to report your data in HTML. I am not sure whether there is any tool or standard way to take XML and present in Excel or PDF. If not, you can do it yourself, or rescope of what you are trying to do. Try to utilize and follow industrial standard is always a good idea.	[reply]
Re: Re: OO Design -- Separating Data from Presentation by dragonchild (Archbishop) on Dec 13, 2003 at 05:19 UTC
PDF::Template and Excel::Template, combined with XML::Parser (which they already use cause the layout/template files are in XML) and some code anyone can write should be able to do this. I didn't extend the param() method for those modules beyond what HTML::Template's does because that wasn't in my initial scope. But, there's no reason I couldn't accept an XML document (either filename, filehandle, or scalarref) as the parameter list ... unless I'm missing something obvious (which is always a distinct possibility). ------ We are the carpenters and bricklayers of the Information Age. Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.	[reply]
Re: Re: OO Design -- Separating Data from Presentation by xenchu (Friar) on Dec 13, 2003 at 02:54 UTC
Perhaps the Spreadsheet::WriteExcel would serve or perhaps XML::Excel? I haven't read the documentation but their purpose seems to be to read and write Excel spreadsheets. xenchu **sigfilesigfilesigfilesigfilesigfilesigfilesigfilesigfile* Perl has one Great Advantage and one Great Disadvantage: It is very easy to write a complex and powerful program in three lines of code. ****************************************** `The Needs of the World and my Talents run parallel to infinity.`	[reply] [d/l]


There's more than one way to do things
	PerlMonks