[LRUG] [Bulk] Best practice for reports

[Paul Doerwald]

Hi Daniel and Tom,

Thanks for your responses!

Daniel — heh. I recreated a pattern, eh? That's pretty cool. The  
presenter pattern raises some interesting ideas. I guess my third  
approach is better than I thought, having read Jay Fields and Martin  
Fowler on it. I'm going to have to fiddle with their ideas a bit.  
Field's approach isn't perfect for me (it's geared to presenting  
forms, whereas I'm interested in processing large amounts of data and  
presenting it), but I like Fowler's approach in the abstract.

Tom — Thanks for your thoughts. It's definitely the simplest  
approach, and your variation on my suggestion cleans up the view a  
fair bit... but I worry if I add too many such methods to the model,  
I might break a nice logical encapsulation.

I think in my case, using the presenter pattern will probably be  
wise. My application will end up very report-heavy, full of number- 
crunching, and I think it makes sense to move that functionality into  
its own hierarchy of classes where functionality can be reused more  
easily without necessarily polluting the model. A bit of overhead,  
but it seems that it might be worth it. It's comforting to know that  
this approach has been thought of before. I'll blog about what I come  
up with (http://pauldoerwald.ca !)

Thanks for all your insight and pointing me at the presenter pattern!
Paul.


On 21-May-07, at 6:12 PM, Daniel Lucraft wrote:

> Hi Paul,
>
> It may help you to know that what you are calling a 'report' is  
> called a
> 'Presenter' in the rails world, which should help you with googling.
> Kudos for independently inventing a design pattern. :)
>
> If you google for "ruby rails presenter" the top two articles by Jay
> Fields do exactly what you do, and he seems to think it's a good idea.
> Other people have talked about Presenters in the context of rails best
> practice.
>
> Personally I would only go this far if (1) I was extremely serious  
> about
> doing things right and testing properly or (2) the complexity/size of
> the code made it look like a good idea.
>
> Other people with more experience may feel different.
>
> best,
> Dan
>
> Paul Doerwald wrote:
>> Hi everyone,
>>
>> I'm asking this question in the interests of separating business  
>> logic
>> from presentation. I have a standard reporting problem — I have a  
>> bunch
>> of data in a database, and I want to dig through it, sort it, sum it,
>> frob it, average it, and display it.
>>
>> The easiest way to do it is in the view:
>>
>> <th><%= f.name</th><td><%= Foo.count(:conditions => "blah") %></td>
>>
>> but then I've committed the heinous sin of putting the business
>> (reporting!) logic into the view. I could avoid that by stuffing  
>> it into
>> the controller, essentially mimicking the table structure, but in  
>> a hash
>> of some sort:
>>
>> report = Hash.new
>> report["Baz"] = { :name => f.name, :sum => Foo.count(:conditions =>
>> "blah") }
>>
>> But I'm not convinced that I'm winning anything here.... plus the
>> "Rails" way of doing things is to move the logic out of the  
>> controller
>> into the model... but then what if I'm pulling data from half a dozen
>> different tables? Presumably then I need to create a new
>> (non-ActiveRecord) model, perhaps:
>>
>> class Report
>>   class self.main_report
>>     # create the hash here
>>   end
>> end
>>
>> But that is just indirection another step away, so what I really  
>> should
>> do is:
>>
>> class Report
>> end
>>
>> class MainReport < Report
>>   attr_accessor :title, ...all the other fields I might want to  
>> use...
>>
>>   def frob
>>     # prepare the report
>>   end
>> end
>>
>> and then in the controller, instantiate the MainReport, and do the
>> looping in the view... but now I've created a whole lot of work for
>> myself to simply do what I could do with much less effort in the  
>> first
>> instance.
>>
>> I suspect the last option is probably the best — at least of the ones
>> I've presented — but I'm more interested in what others have read  
>> about
>> or done which they feel is the "best practice" for reporting.
>>
>> Along this thread, has anyone used http://rubyreports.org/ ? Is it
>> appropriate for me? I haven't looked closely yet, but am about to.
>>
>> Thanks,
>> Paul.
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> _______________________________________________
>> chat mailing list
>> chat at lrug.org
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> _______________________________________________
> chat mailing list
> chat at lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org